Title: S16 E10: Eric Voskuil & John Carvalho on Bitcoin & Austrian Economics
Podcast: Bitcoin Takeover Podcast (host: Vlad Costea)
Guest(s): Eric Voskuil (maintainer of libbitcoin, author of Cryptoeconomics) & John Carvalho (CEO of Synonym, the company behind Bitkit)
Published: 2025-02-26
Duration: 8:21:14
Episode URL: https://bitcoin-takeover.com/audio/?name=2025-02-26_s16_e10_eric_voskuil_john_carvalho_on_bitcoin_austrian_economics_-_24.02.2025_12.07.mp3
Audio: https://bitcoin-takeover.com/audio/media/2025-02-26_s16_e10_eric_voskuil_john_carvalho_on_bitcoin_austrian_economics_-_24.02.2025_12.07.mp3
Transcript: CORRECTED. Base: local Whisper medium.en transcript with automatic diarization (recorded live, 8h21m), reconciled three ways against a full-episode local small.en re-transcription with word timestamps and an independent local Whisper (tiny.en) transcript of the same episode from the bitcoin-forks-research archive (word-level diffs per section). 68 doubtful, dropped or garbled stretches were re-transcribed locally from short audio clips with medium.en (30 + 29 + 9 clips). Dropped or garbled stretches were restored at 00:27:04 (Mises on gold and price inflation), 00:50:16 (supply/demand as subjective value), 01:34-01:36 (BTC1/BTC2, right to fork), 02:03:41 (mempool transactions as credit), 02:50:24, 03:00:01-03:00:43 and 03:22:38 (block size scaling debate), 05:56:34 (Bitrefill zero-conf), 06:21:38 (first seen vs last seen), 06:50:58 (NGU and deference to the state) and 07:04:27 (FIBRE/Stratum V2/Dandelion); hallucinated speaker names inserted by the recogniser (CHRIS COLEMAN, NICK CORREA, BILL BAILEY, DANIEL RODRIGUEZ) and hallucinated 'Thank you.' fragments (04:49, 07:28) were removed, and a duplicated interjection at 06:43:59 was dropped. Speaker labels (Vlad Costea, Eric Voskuil, John Carvalho) were fixed with a full-episode local TitaNet speaker-embedding scan (reference voices for all three) used to split and re-attribute turns word by word, plus manual fixes (e.g. 00:01:08, 00:50:17, 02:44:39, 02:54:48, 03:06:41, 04:12:36, 04:21:46, 05:57:28, 06:22:13, 06:30:14, 07:01:22, 07:19:04, 07:39:16, 08:03:48). Names and jargon were checked against the title, the show notes and the web: libbitcoin, bx/SX, Cryptoeconomics, Synonym, Bitkit, Bitrefill, Counterparty, Mastercoin, Omni, OP_RETURN, Tether/USDT on Tron, Mises, Menger, Rothbard (Man, Economy, and State with Power and Market), Cantillon, seigniorage, demurrage, Marshall, Zimbabwe bond notes, Mugabe, BIP34/BIP90/BIP30, BIP-37, Neutrino, BOLT 11/12, drivechains, Paul Sztorc, LayerTwo Labs, Citrea, ZK rollups, Zano, DarkFi, Halo 2, Monero, Mimblewimble/MWEB, Dark Wallet, DarkMarket, DarkLeaks, OpenBazaar, Airbitz/Edge (Paul Puey), Amir Taaki, Cody Wilson's apartment in Austin, phantomcircuit, Andy Greenberg, Peter Todd, John Dillon, Greg Maxwell, Pieter Wuille, Ava Chow, Gloria Zhao, Luke Dashjr, Bitcoin Knots, Unhosted Marcellus, mempoolfullrbf, opt-in RBF, first seen, zero-conf, CPFP, P2Pool, Braidpool, Ocean, Stratum V2, FIBRE (Matt Corallo), Spiral (Matt Corallo, Steve Lee), Mara, Dandelion, Kulpreet, Great Consensus Cleanup, time warp, 64-byte transactions, Merkle tree malleation, FindAndDelete, OP_ROLL, SHA-NI/AVX2, Utreexo, assumeUTXO/IBD, Delving Bitcoin, Temu, Chia/Bram Cohen, Blockstream, Adam Back, Michael Saylor/MSTR, Milei, BTChip/Ledger, Eric Larchevêque, Disqus, Trezor, Bybit hack, SCIF, MinGW/Mersenne Twister, Milk Sad (CVE-2023-39910), Tadge (Dryja), Antoine, Nick Szabo's social scalability, HODLING.ch, NoOnes, SideShift. Light clean verbatim: ums, false starts and stutters were removed, and factual slips by speakers are kept as spoken. Chat handles (iCust007, Andrea) are kept as read out. The intro music (0:00-0:46) is omitted. Remaining doubtful words are marked [unclear: best guess] (19 places).
================================================================================

[00:00:46] Vlad Costea: Welcome to the Bitcoin Takeover Podcast. This is Season 16, Episode 10. This episode is sponsored by SideShift, Citrea, Bitcoin.com News. You're going to roast me for this one, John. LayerTwo Labs, NoOnes, and HODLING.ch. And we are live with John Carvalho and Eric Voskuil in an episode that's going to be very controversial. Hello, gentlemen.

[00:01:08] John Carvalho: Hey, Vlad. Hey, Eric.

[00:01:09] Eric Voskuil: Hi.

[00:01:10] Vlad Costea: So obviously, we're not very happy about the state of Bitcoin these days. We seem to be pushed in a position where we have to become friends with the guys we used to pretend to hate.

[00:01:24] Let's start it from here. How does it feel to be winning, to be mainstream?

[00:01:32] John Carvalho: Is that where we are? Is that what Bitcoin is, mainstream now? I definitely think it's come a long way as far as, you know, calling it mainstream. You know, it's getting talked about by presidents and, you know, we have El Salvador, you know, tweeting about how whenever they're buying Bitcoin and this kind of thing. But as I'm sure the panel will agree, Bitcoin was not necessarily made to be embracing government. It's kind of anti-government. And I think Eric would say that white market Bitcoin is not really feasible. And it sucks because it seems like, obviously, most of the motivation of Bitcoin is to speculate on getting rich through it, and thus that leads many people to just behave like Ponzi evangelists.

[00:02:23] Vlad Costea: Number go up, right? I mean, I remember when Chris DeRose was talking about this, and I used to think he's insane or that he lost it or something. It seems like he was just a bit ahead of the curve and he was able to first see what's coming.

[00:02:42] John Carvalho: In some ways. I mean, Bitcoin Uncensored was pretty spot on with a lot of things, but he also believed in Bitcoin Cash and kind of went for a loop towards the end. So I don't know what to say there.

[00:02:56] Vlad Costea: He was also the marketer for Counterparty for a long time. And he was one of the first toxic maximalists in this regard, because he was of the opinion that Ethereum is basically a waste of time and Counterparty can whatever Ethereum does. I think Vitalik's article from 2015, which describes what he called at the time Bitcoin maximalism, was the response to this reaction where people said, yeah, whatever, play with your Ethereum, but we can just copy and paste the code into Counterparty and make it happen on Bitcoin.

[00:03:34] And that seemed to be the prevalent attitude at the time. And this was what Bitcoin maximalism used to be about. Now it's about just saying everything is a scam.

[00:03:47] John Carvalho: I mean, there were always people saying dumb or slash interesting things about Bitcoin maximalism, but generally everything got really dumbed down. And I kind of think of it more like maximizing the, you know, how much people can use Bitcoin or how many people use Bitcoin, how many transactions, whatever, just trying to optimize that quantity. But, yeah, I think in early days, most of us did just mean hyper Bitcoinization. Everything, you know, Bitcoin is a black hole. Everything is going to have, going to succumb to the gravity of Bitcoin.

[00:04:21] There'll be nothing left. I don't think any of us believes that anymore.

[00:04:27] Vlad Costea: But it's funny, right? People look at the mempool today and they say, see, we told you we don't need to increase the block size. We told you we don't need to scale in any way because there is no demand for block space. We were very smart to keep it small because it seems like there is no real demand for it. And in the meantime, people pay four dollars to transfer USDT on Tron.

[00:04:52] John Carvalho: I didn't realize Tron had become that expensive for Tether.

[00:04:56] Vlad Costea: It did, because people use Western Union or MoneyGram as a point of reference. And I think there's a website, it's called Tether Gas Fees or something, and it compares how much it costs to send USDT across multiple networks. And Tron is usually between two to six dollars.

[00:05:21] And Bitcoin is what, 30 cents right now?

[00:05:26] John Carvalho: Right. But in the end, like you still can't do tokens on Bitcoin because once you get real volume, the fees become extremely high and obviously defend and then defending whatever mechanism you've used to establish those tokens becomes impossible, depending on how you designed it.

[00:05:44] Vlad Costea: Yeah, but coming back to the idea of Bitcoin maximalism, Tether started on Bitcoin on the Omni layer or Mastercoin.

[00:05:53] John Carvalho: So it's funny too, because I always thought, sorry, go ahead.

[00:05:57] Vlad Costea: No, you always thought what?

[00:06:00] John Carvalho: I always thought Omni was just simple enough. In other words, we don't need Taproot assets or it's like, if you want to do tokens on Bitcoin, how much simpler can you get than encoding it inside of the OP_RETURN and just having another layer that interprets the encoding and just use Bitcoin transactions. And you could do lightning channels that way where you have the tokens native in the channels. If that's what you want, just do that. And it's so simple. But nobody wanted to revive Omni.

[00:06:28] Everybody let it die once everything moved to altcoins. Then everybody wanted to reinvent tokens on Bitcoin.

[00:06:38] I also think Omni was the first layer on Bitcoin.

[00:06:42] Vlad Costea: I think it was Counterparty. It was launched in January of 2014. And in March, I think Mastercoin was launched.

[00:06:52] John Carvalho: I don't remember how Counterparty works. Is it like the consensus? Is it merge-mined? Or I don't remember if it's actually just a separate, totally separate blockchain or what?

[00:07:02] Vlad Costea: No, it's not a blockchain. It's a protocol that uses OP_RETURN, just like Omni. I'm not sure about the specific differences between the two. I think Counterparty somehow

[00:07:12] John Carvalho: Ended up with its own token you had to use, whereas Omni did make an ICO token, but you never had to use it.

[00:07:22] Vlad Costea: So for Counterparty, if you wanted to issue an asset, only if you wanted to name it something, you had to use the Counterparty token. If you only use Bitcoin for it, you would get something that's called like an unnamed asset, which has a random string of letters and numbers in it. So if you wanted sort of a vanity asset, you had to burn 0.5 Counterparty tokens or something.

[00:07:55] You're muted, John.

[00:07:59] John Carvalho: I was saying we were talking about how we're unhappy with Bitcoin, and now we're into the history of tokens. I'm not sure where we want to go.

[00:08:05] Eric Voskuil: Yeah, I'm not even in this. I don't know anything about tokens. I never cared. So you guys can have a conversation about it.

[00:08:13] Vlad Costea: But what's a token anyway? Is it just a non-Bitcoin asset that's issued on the blockchain?

[00:08:21] Eric Voskuil: I mean, to me, yeah, sure. But there's no point in it. I think very, very early on, I don't know, 2013, when I first started looking, I was like, this might be interesting. I look at colored coins. And then it didn't take long before I realized that whatever it was that was providing the security model of Bitcoin provided nothing in that context. So I just didn't see any point in it. And that doesn't mean you can't build up a lot of infrastructure and spend a decade working on it, and it appears to work.

[00:09:05] The point is that it can be subverted trivially. So it's a custodial problem, right? The way money works is, first of all, people don't really understand money. Obviously, there's a lot of opinions on money. But money is the thing that doesn't represent anything else, right? For example, a silver certificate, say old US gold certificate, silver certificates, those are credit. Those aren't money. Those are a certificate that promises you to get the other thing that it certifies. That other thing is held by a custodian. In that case, the US government, the Treasury, Federal Reserve, whatever.

[00:09:54] The original current US dollar before it was delinked from gold was a gold certificate. You could take it in and get your gold. It represented something else. And of course, that something else depended on the fidelity of the custodian, which in that case would have been the Fed. The custodian defaulted. Very easy. The gold standard worked for them, didn't work for anybody else. Because the custodian was the weak link in the security model. So look at Bitcoin. Well, sorry, step back a little bit more. Now, we have the US dollar, which is not backed by anything.

[00:10:40] So it's not a certificate. It doesn't represent anything else. It's just money. Bitcoin is going back to take it back all the way to Mises. They don't want to admit this. It actually is money. Because it's government, it's a tax, and I'm an anarchist, I understand all that. But I deal with reality. The dollar is money. It's not credit. The reason it's money and not anything else is because apart from being used as money, it doesn't represent anything but itself. It doesn't represent a promise to get anything from anybody.

[00:11:18] It's a hope that somebody will value it more highly than you do, so you can trade it for something. That's what makes it fiat. It's not anything else. It's just money. And that's what makes Bitcoin fiat. It's not anything else. It's just money. Dollars can be used as straws and wallpaper and toilet paper, and Bitcoin can be used for time stamping, et cetera. But those uses don't exist. The money doesn't exist without being the money. The money is really the thing. And that's what makes it fiat by definition, basic economics definition.

[00:11:59] That's what makes it money. Money as opposed to credit. So money doesn't require a custodian. That's an important observation. Gold doesn't require a custodian, somebody to trade your gold in for whatever it represents. Silver, dollars, present dollars, old dollars, they did, and it failed. Bitcoin, nobody's a custodian of your Bitcoin. Nobody exchanges it for the gold so that you can get stuff. You get it because somebody else is willing to trade you for it, and that's it. So it's a social consensus, whatever. So as soon as you take that concept, and you slap on a custodial and completely unrelated feature, like we're going to use this Bitcoin mechanism to time stamp the existence of a contract that represents whatever.

[00:12:54] Say it represents gold. So we tokenize gold. I own the gold because I own the keys that can sign for the certificate that says I got the gold. So it's a gold certificate on Bitcoin, token, color coins, same thing. Well, where's the weak link in the security model? It's the guy who's got all the gold, who's the custodian for the gold. So say it's concert tickets. It's the theater. It's the stadium who physically controls the seats. They could say screw your Bitcoin colored coin ownership of that seat.

[00:13:28] If it's land deeds, you remember, you know, South America, Latin America was all going to put all their, because they always had these problems with deeds and land. They would just put it on the blockchain. It would tokenize it, and they could prove who owned it. Well, the problem is that the problems that exist in those parts of the world aren't because they lost the records. It's because the custodian isn't trustworthy. Custodians, like take Zimbabwe, right? Custodians, you know, say you put all your land deeds on the blockchain, and the custodian says, great, we're going to honor whoever can sign the certificate owns the land.

[00:14:13] And it can trade freely, and we'll honor that. And then one day, they wake up, and they say they're not going to honor that because of political whatever, right, which they've done. They're doing, say, now in South Africa also, which they've done in Latin America many times. So how did tokenizing it solve anything? Nothing. It didn't do anything. It just gave people a false sense of security. It's the same problem as the oracle problem, essentially. The custodian physically controls the asset, which generally, publicly, is the courts, the state, whoever.

[00:14:46] They can invalidate the contract. So I just looked at it and said, okay, well, it's interesting, but it's not a more secure model than what we already have, and it's less efficient. Right? I looked at something like take StubHub or Ticketmaster or whatever and just subvert their whole business model by putting everything on blockchain tickets, and the concert stadiums just honor whoever owns the ticket. And so the secondary market is just a natural extension of the primary market, and it's all great. But they don't have to honor it.

[00:15:21] They can just ignore it. So it doesn't change anything, and it's much more efficient for them to just run a website that sells tickets, which is what Ticketmaster is. So again, to me, there's no use case. There's no reason to do it. So I don't work on it. I never have. And that's why I don't know much about it, because I don't care.

[00:15:45] John Carvalho: Why do Bitcoiners talk about money so much and the definition of money? And they want to say medium of exchange and unit of account and store of value and have all these acronym terms that they say these are the qualities of money, and when you meet these checklists, now you are money, and you've graduated to, I don't know what,

[00:16:06] Vlad Costea: World dominance or something. Yeah, and they say that we never had real money before Bitcoin, like nothing else.

[00:16:11] John Carvalho: Or this is the hardest money, right? And so it's clearly the best. There's so many fun topics.

[00:16:17] Eric Voskuil: There's so many fun topics. I'm just trying to figure out,

[00:16:20] John Carvalho: Like, they talk about it so much, so, so much, but they don't care about it so much. In other words, why is money interesting in the first place, right? It's because we use it as a way to do commerce, as a way to have an economy, as a way to make things flow. It's a utility, but they always talk about these qualities, because they think they want to attribute Bitcoin to being something that is inevitable or obvious. I can't quite figure out why they're so interested in it, because I'm interested in these ideas because I want to design things that solve problems and networks and such.

[00:16:55] When I think of it, I'm like, okay, well, should we even care about Bitcoin as money for most commerce? Because we know it can't scale, and why do we keep talking about Bitcoin as money if we're not going to use it as money? You're all just trying to use it as this speculative store value for the most part, and only as money when you finally realize you do want to sell it. I don't know, I'm just ranting a little bit, but that's my reaction when I listen to Bitcoiners talk about money.

[00:17:27] It's just like, stop. Why don't we just talk about something useful?

[00:17:31] Eric Voskuil: Well, you raised a lot of like, I could talk for a long time on most of the issues you raised there.

[00:17:41] Well, first of all, Bitcoin is money, and that's why Bitcoiners talk about money. That to me is pretty self-evident. Some people don't understand that Bitcoin is money or what money is, that's a more interesting question.

[00:17:56] Before Bitcoin exists, I was a longtime libertarian card carrying member of the US Libertarian Party for like 20 years before I gave it up and decided I wasn't an anarchist in the true sense of the word. Until Bitcoin came along, I looked at DigiCash, I was very interested in these things for a long time, PGP.

[00:18:21] And so, you know, I found Bitcoin, I actually had not looked at it for quite some time, because I had followed DigiCash, and I didn't think it was going to work. As soon as I did look at Bitcoin, I've been working on it ever since.

[00:18:41] A stateless money is an important thing, and we can talk about why and all that, but that to me, that's really what Bitcoin is all about. All these other things that people want to do with it, they're interesting, but they're not useful to me. It's not why I'm here. As far as the speculation goes, anything that goes from zero to nonzero has infinite growth. Bitcoin has experienced infinite growth, and speculators are going to speculate on anything that's growing at an infinite rate. That's also self-evident, that's going to happen.

[00:19:15] That community will exist until it gets slaughtered by the lack of perpetual growth. The fact that something's gone from zero to nonzero doesn't mean it goes from zero to infinity. So I've written a lot about that. That's all interesting. So you set aside the tokenizers, you set aside the speculators, and ask yourself why we're here. You asked a lot of good questions about money, and I think you, over the years, expressed a genuine desire to learn and understand that most people don't.

[00:19:49] I can't say that I showed up, even showing up to Bitcoin with all the experience I had reading on economics and politics for years, I can't say that I really understood money until I really had to start trying to understand Bitcoin.

[00:20:07] There's these properties of money, which you enumerated, that the kind of academics will say, well, if it doesn't meet these criteria, it's not money. Or this is basically what money is. It has these three primary characteristics, store value, unit account, medium of exchange. But really, you know, there's no clear line. So people argue forever about whether it's a general store of value or a general, widespread medium of exchange. But money, fundamentally, is just a medium of exchange. Money solves the coincidence of wants problem. And so that's why it exists.

[00:20:53] That's why it evolved. It evolves naturally. It evolved naturally in many different independent societies. And it typically evolved from commodity money. So I have this interesting rant about Mises. And I think maybe I could focus my comments here a little bit. A lot of Bitcoiners see themselves as libertarians, at least kind of early cypherpunk-type Bitcoiners. And they gravitated towards Austrian economics, which, by the way, is not related to Mises being Austrian. It's related to I'm going to blank his name now.

[00:21:46] I'm awful with names. It's fucking embarrassing. I'll think of it in a minute. Anyway, early economists who was in Austria were the primary. The academics were all in Germany at the time. Austria was like backwater. So it was derogatory, this Austrian guy. But value, so this is where value is subjective comes from. It comes from the Austrian school, solving the definition of value. Because Adam Smith didn't get it right, and of course, nobody else had it right. We have the diamond water paradox. Why is water sometimes more valuable than diamonds?

[00:22:24] And then so we get the Austrian school, which says, hey, value's subjective. And we're getting Menger. OK, thank you. So Menger, who also deserves, there were two guys, I can never remember the other guy, that kind of co-developed the idea the same year, but the idea of subjective value. And so it's all really interesting. It goes forward. It gets improved upon, as economics has been since the time of Adam Smith. And Mises comes along, who's another in the line of Austrian economists who believe that value is subjective.

[00:23:01] And Mises, I think rightly so, is critical of state money. But he's so critical of state money, he loses his objectivity. And I'm critical of state money. I know it's a tax. But Mises makes a number of critical errors. And those have been, so I'm a big fan of Rothbard. And not all of his writing, but Rothbard's Man, Economy, and State with Power and Market. It was originally intended to be kind of an update of Mises. I think he was hired by Mises Institute to write this thing, to kind of bring Mises up to date, to make him contemporary.

[00:23:49] And he's very careful not to make some of the errors that Mises makes. And he doesn't make some of the errors that people attribute to him to this day that he makes in other books. So he's being formal, and he's being careful. And so a lot of Bitcoiners who see themselves as libertarians or anarchists and who adhere to the Austrian school, which the idea of subjective value, get really adamant about their understanding of some of these ideas that they took from Mises or a misreading of Rothbard, which they aren't alone.

[00:24:29] A lot of others have done the same thing. And so this gets to the idea of money. So I'll be more concrete. So when Mises, in trying to denigrate state money, goes overboard, he rightly points out that he tries to argue that paper money issued by the state is not money. Well, gold's money, paper money is not money. That's just not true. It's clearly money. So why is he trying to do that? Well, he's trying to do that because he's trying to denigrate state money. Why is he trying to do that?

[00:25:04] Because it's a tax. But what makes it a tax? Is it a tax because the government creates it? No. If the government dug gold, it wouldn't be a tax. So he makes this argument that the creation of money itself is price inflationary. OK, so this is another thing that modern Austrians will do. They draw this distinction, which is there's a distinction between monetary inflation and price inflation. Monetary inflation in these terms is any creation of money. There's new units of money. Price inflation is the decreasing purchasing power of that money for whatever reason.

[00:25:59] And there's a clear link drawn in their minds between monetary inflation and price inflation. And I'm always careful when I'm speaking specifically, clearly, I will make the distinction between those two terms because people get all up in arms about which one you're talking about. But this is a quantitative view of inflation. In other words, strictly the quantity of the money, the increase in the quantity is monetary inflation, and the decrease in its purchasing power is price inflation. And the dots that connect those two are supply and demand determine price.

[00:26:46] Increasing supply, which in their minds means quantity, means a decreasing purchasing power, a decrease in the price of the money. So why do I say this is an error by Mises and by everybody else?

[00:27:07] So Mises goes on to say, clearly, he's trying to draw out the critics ahead of time. He's trying to end run the critics who will say, well, wait a minute. Gold is not price inflationary. Throughout history, gold has not exhibited price inflation. It exhibits price volatility, but not a persistent unidirectional inflation, which you would expect because it has been continuously mined.

[00:27:40] There's still a lot of gold produced every year. So I quote the response he gives to his own kind of straw man, or his own, it's not really straw man. He's, what do you call it, steel manning, I guess.

[00:27:51] And I quote him. And despite being fairly rigorous in other aspects, most aspects of the book, he just completely gives it a hand wave. He says, I can't really explain it, but this is how it works, basically. He says something like, everything's really complex and interrelated and therefore blah, which basically means he's full of shit because by his own criteria, economics is an axiomatic system. In other words, you have a set of axioms, you derive principles from the theory, right? And he's not able to do that.

[00:28:23] But why isn't he able to do that? Because it isn't true. He doesn't understand what's really happening. He has a desire to denigrate money. So he takes one truth and he extends it to another situation where it's not a truth because he doesn't understand the basis of the truth in first place. So then I'll set that aside for a second. And I don't know if you said seven hours there, so I'm going to just ramble as long as I want. But then you take like the names again, Cantillon, right?

[00:29:03] You take the Cantillon effect, which he refers to in Human Action as well. And so I looked up Cantillon, I looked up all the history of like, none of these things were like first, Cantillon was the first to make these observations. These go back much further. Same thing with their name.

[00:29:32] Think of it. So Cantillon effect is this idea that the creator of the money, in this case, gold, Cantillon was observing gold mining, issues the money, gets the greatest purchasing power out of it, and then as it moves through the economy, it's a decrease over time. And so people have taken this, Mises took this kind of as fact, and Bitcoiners love this idea. And of course, it's a legitimate idea, and Cantillon was observing a real phenomenon. But Cantillon points out that the gold is being mined in the king's mines.

[00:30:09] This is not market mining. This is the king, who legally controls all of the gold mining and wherever he's talking about. So an ounce of gold might buy a donkey, and the king, who mines all the gold, can charge whatever price he wants for the new gold. He's got monopoly control over the production of the gold. Nobody can compete with him. Nobody can lower the price.

[00:30:44] So he can make a coin, put a one on it, say, here's one, and nobody else can go make a bunch of other coins at lower cost and bring the price down. He can actually increase the price over time and just charge whatever he wants, as long as people are willing to pay it. So that difference between the cost of it being mined and the purchasing power that it has is under monopoly control is seigniorage. Seignior refers to the king, right? The person with the privilege of being able to have the ability to charge more than it costs to produce, right?

[00:31:25] And when I say cost to produce, that includes your capital cost, the profit. You would make maybe 10% on doing the work. That's part of your cost, pays for your time. So competition is what brings prices of all things down to their costs, inclusive of capital. And the purpose of, say, compulsory labor unionism or monopoly control or patents, the purpose of all these things is to prohibit competition using guns so that you can charge whatever the market will bear, not what it costs you to produce.

[00:32:04] That's called a monopoly price. And the production of money, seigniorage, is the profit that you make, which is above your capital cost, right? In economics, profit is the amount above your capital cost. Profit that you make is a privilege that you get for being the king. And Cantillon was observing the king's minds, right? The king got a better return from the money than everybody else did on down the line. What if those mines are not under monopoly control? Then the money is produced at market price. There is no seigniorage, and there is no tax, and there is no what we call Cantillon effect.

[00:32:47] He was not observing a market production. So we fast forward to Mises, and Mises attributes the Cantillon effect to market production of gold. Yet he cannot explain why competition in market production of gold does not bring the price down to market price, or even if it does, why the production of new units is price inflationary, given that those new units are produced at the market price. He acknowledges that it doesn't make sense, and it explains it away as it's complicated. It doesn't make sense. And this is one of the most important concepts that Bitcoiners do not understand, right?

[00:33:33] The production of money or anything at market price does not create price inflation of the thing that's being produced. It's actually what keeps the price stable. So dollars backed by gold, if you were to trust the custodian with gold being produced in a free market, are not inflationary. And US dollars, to a great extent, were very low inflation state money. They were still inflationary because the custodian wasn't really trustworthy. But as long as they were freely exchangeable, they maintained a very, very low rate of inflation. But there was still ongoing gold production.

[00:34:24] And people were still trading in new gold for dollars. So what happened? You decouple the gold from the dollars. Why do you do it? Well, the same reason you created the system in the first place. So you can do it, right? Now you can print dollars. So why are dollars then price inflationary and gold is not? Well, it's not because the state's printing them. It's because nobody else can print them, right? It's the same issue. It's monopoly protection of the production. If you and I and everybody else in the world could freely print dollars, genuine, bona fide, high quality, same difficulty production, exact same dollars, we could produce them.

[00:35:09] They would get produced to the point where they were being produced at market cost. And each $100 bill would have the purchasing power of about $0.20 today. We'd have a portability problem, but we would not have inflation. And that's actually what happens when the state prints, prints, and prints. Eventually, it's inflated the currency so much that those units are no longer profitable. So you get to the point where it costs $0.03 to make a penny, you're going to stop making pennies. And that's what we're going to do.

[00:35:45] You go to Vietnam. The last time I was there, I think it was 5,000 dong was the lowest unit they had. I'm pretty sure they started at one. But 5,000 dong was worth, I don't know, about five, maybe it's 1,000. It was about $0.05. And I looked it up, and I'm like, that's about what it costs to make it. This is going to go away pretty soon. OK, so state money is inflationary because of anti-counterfeit laws. It's because of the monopoly privilege.

[00:36:17] And every state that makes its own money accounts for seigniorage, which is a profit on the printing of the money. There's no profit on coins. They're produced at face value.

[00:36:30] But that seigniorage is attributable only to the monopoly production. It's not attributable to the production in general. And that is a huge Mises error. It's not an error that Cantillon makes, but it's one that gets attributed to him because people don't understand. They don't see the fine print there. He says, the king's mines, right? Which I remember reading, going, OK, there it is, right there. He knew what he was talking about. Gresham, he understood why the money would go away. People would hoard one money versus the other because a monopoly producer was effectively clipping the coins, right, debasing the money.

[00:37:15] Why could it do that and nobody else? Because it was illegal for other people to do it.

[00:37:22] So Bitcoin is produced at a market price, right? The fact that there is a constant rate of production tends to confuse the issue for people, but it's not actually any different. But it does cause people a lot of confusion.

[00:37:45] When you're mining gold, and the demand for gold for some reason has gone up. Maybe we're sending a lot of ships into space, and we need a lot of gold, whatever. And the price starts rising. Well, what happens? More competition comes in, find more gold, they mine more gold. Supply increases, price comes down, and the price of gold stays constant, right? Price of gold drops. The demand for gold drops. People just stop mining it. No more gets produced. So it's not flexible in both directions. Bitcoin is, right?

[00:38:24] When Bitcoin is being produced, if the demand for Bitcoin is going up, block production increases, the rate of production increases. The difficulty adjustment kicks in periodically and says blocks are coming too fast, it increases the difficulty, slows blocks down, becomes more expensive, produce Bitcoin, and it returns to its cost. And of course, people predict these things, so it stays fairly extremely close to the cost line. The cost of producing Bitcoin stays very close to its market price. It works in both directions, though. We have difficulty adjustments downward as well.

[00:39:03] And so the amount of Bitcoin being produced does not change. But it's still, just like gold is produced, all of it is always produced at the current market price or the best information available as to what the market price is. So certainly volatile, but there is no seigniorage, which means there's no price inflation in Bitcoin production.

[00:39:33] So why is that more confusing? Well, it's because the quantity does not change, unlike gold. But the difficulty of producing it, the cost of producing it changes, and gold's cost of producing it generally doesn't change, right? If you just take a constant cost of production, what's going to happen? Price rises? It'll just be more people producing. More of it will get produced at that constant cost, right? So the theory is very simple. The quantity varies in gold, where the cost varies in Bitcoin. But price is a constant.

[00:40:06] It's a result of supply and demand, right? And if you change either one, you've affected the price, and they both do this. So it looks like my son is moving, and I'm washing out, which is cool. So I could say a lot more on it. I'll pause there. I'll let somebody else talk for a bit. But money confuses people, and we get a lot of things. We can talk about fractional reserve, again, Mises, Rothbard not making the error. He never made that error that Mises made with the Cantillon effect, and he didn't make the error with fractional banking that people think he did, or the statements.

[00:40:48] But so much energy in Bitcoin has been put towards this idea that production of the money is inflationary, even Bitcoin, right? That production of other currencies, altcoins, for example, is somehow, if we allowed that, then there would be infinite inflation, and all the money would be worth zero. Well, clearly, that's not observable. So what's wrong with your theory, right? So there's clear, stark errors with people's understanding. And I've been beating on this drum for 10 years, and some people have come to understand, but most people, they read the Bitcoin standard, and then bullshit Mises economics, and some other stuff that wasn't from Mises, and that's it.

[00:41:45] They're absolutely convinced. They understand how things work. And I've just seen so much of what drives the community being driven by that nonsense, that it's not surprising to me at all that huge amounts of time were wasted, and we don't make the progress that we think we should be making.

[00:42:08] John Carvalho: It took some notes while you were speaking, because I don't know that I have anything totally coherent, but a few maybe questions or statements. I really liked when you kind of made me think about that what we call the Bitcoin subsidy isn't subsidy, because it's paid for at market rate. I was a little disappointed, because you used the word subsidy in your 21 questions interview with Vlad that I watched yesterday.

[00:42:34] Eric Voskuil: [unclear: The technical problem with using] Bitcoin for the quantity of production, but it's not a subsidy in the sense of somebody's paying for somebody else's stuff, right?

[00:42:43] John Carvalho: Yeah. But as you would agree, the semantics become really important, because Bitcoiners love interpreting things the slimy way. And so when you use it, they're like, oh, he means subsidy.

[00:42:58] Eric Voskuil: Well, it's ironic. They'll argue about the words incessantly, and then come back to me and saying, I'm just playing semantics game.

[00:43:05] John Carvalho: I'm like, no. I see it all the time. I watch your arguments, and it's like, yeah, you're just being semantic. Oh, you shouldn't have said that.

[00:43:12] Eric Voskuil: I'm talking about supply and demand. We're talking about price. We're talking about supply and demand, right? There's an economic relation we both agree on, that supply and demand determine price.

[00:43:21] John Carvalho: What I think people don't like is the nuance you were describing, which is like, when you talk about how you have monetary inflation, they're going to assume that monetary inflation obviously does have a relationship to price inflation, but it's diffused and made a mystery by the function of supply and demand. And so you don't even know if the money, so depending on how the money inflation is distributed will partially depend on what market rate it was paid. And then the Bitcoin market rate that's paid is also highly variable, because oftentimes, the cost to mine a Bitcoin and produce it is significantly cheaper than the market rate.

[00:43:56] And so there's all these kind of variables where nobody knows how to just say, point to a phrase or an algorithm or a function that says, oh, supply and demand isn't enough for them, because they want to be able to attribute all of

[00:44:07] Eric Voskuil: These things. OK, so this goes right to the semantic question, right? Supply and demand is an economic concept, and it only holds true to the extent that you know what the word supply and demand mean. Price, which is the point at which two people trade, is a consequence of the supply and the demand. But the supply is not a quantity. In economics, this is absolutely crystal clear. And every time I have to point people to academic work and say, look, you're not talking about supply, they get all freaked out.

[00:44:40] They say, well, you're just talking semantics. I'm like, that's the meaning of the concept in economics of how price is determined.

[00:44:48] John Carvalho: Price is not determined. Well, I think they want to hear it as like, OK, there's an available supply and then the limit of the supply, which is the capital unit. You can use those

[00:44:58] Eric Voskuil: Terms, but they're never clear enough, right? The available supply is in one context correct and another context incorrect, right? You really have to know what it means.

[00:45:08] John Carvalho: And you don't even know what's available anyway, and what's available can change.

[00:45:11] Eric Voskuil: But you do. But people who don't understand it don't get it, right? And so this goes back to the Menger. Menger, in defining the concept of subjective value, quantity is not subjective. Quantity can be measured. It's objective. So as soon as you start talking about supply as a quantity, you have gone back to objective value, and you are wrong. You are wrong to use. You're not wrong maybe in somebody else's system or theory, but you're wrong to use the equation or the relation of supply and demand determining price.

[00:45:47] Because when you say supply and demand determine price, you're using Menger's subjective value concept. And that depends on you understanding that supply is not a quantity because that would be objective.

[00:46:02] John Carvalho: And it's also relative to you, right? It's the supply available to you, not the supply available to everyone. What is

[00:46:09] Eric Voskuil: The supply available to you? It's what another person is willing to trade at. So your demand, say we're talking about gold, I guess. Your demand for gold and somebody else's demand. I see something else. Horses, right? Your demand for a horse and somebody else's demand for a horse. So I've got something I want to trade for a horse because I'm demanding that horse. And I go to market, and I say, I'll trade anybody this for this horse. And somebody's got horses, and they're willing to trade to get something for that horse.

[00:46:40] They don't really care what, but they want something that's worth more to them than the horse, OK?

[00:46:47] So both parties demand the horse, right? The person who wants the horse demands the horse, and the person who has the horse demands the horse more than a lot of other things he could get for the horse, right? Both parties have demand for the horse. So the supply of the horse, you can think of it as the counterparty's demand for the horse. It's the negative demand, right? I have demand for a horse, and I have demand for a horse. But we both value other things more, and we trade.

[00:47:18] So when you say supply available to you, it still sounds to a lot of people like a quantity. It's not a quantity. It's the desire of that other person to unload that horse for maybe a cow. That's the supply. It's a demand. So it's

[00:47:36] John Carvalho: Subjective value.

[00:47:37] Eric Voskuil: It's subjective. So Menger describes both parties as having their own subjective values. He doesn't break it down into like, here's a bunch of quantity, and here's one guy that shows up and demands all the quantity from nobody, right? It doesn't make any sense. He lists scales, and Rothbard does this, Mises does this. Everybody repeats this exercise that Menger went through, where you rank this party and this party have a list of things that they prefer over everything else they have, right? So I've got a horse. I've got a cow.

[00:48:07] I've got a couple of donkeys, some sheep, some chickens, some land, a house. I've got all these things that I can trade. And the other person has all these things they can trade. And I rank them in priority of I would trade of my own things. I would prefer this over this over this over this over this, right? And the other person does the same things. We come to market with our value scales, and we say, he's got something I value more than this thing that I value, right?

[00:48:31] And we trade. That's it. Perfectly symmetrical in that sense. Not symmetrical in that everything stays equal. Both parties after a trade are wealthier, positive sum game, right? Another error. You know, Bitcoiners don't really make that, or they tend to understand that trade is positive sum. But the trade itself, the process is symmetrical. There is no supply on either side. There's just two demanders. It's just that when we start using money as an intermediary, we start thinking of the person with the money is the demander, and the person with the non-money is not the demander.

[00:49:06] That's nonsense, right? Both want to maximize their money by not giving up some or receiving more. And both want to maximize their value to them. So trade is a process of two people supplying and two people demanding. They're both demanding the thing they're giving up and the thing they're receiving. And once you understand that, you understand that the quantity is not supply. It can't be. It isn't. Formal economics makes this absolutely clear. But no Bitcoiner understands this. I mean, there's a handful that do, but they don't understand this.

[00:49:48] That's how you can explain why Cantillon is right, why Mises is wrong. The increase in the quantity of gold does not change is not an increase in the supply inherently. It could be related to an increase in supply, but supply, being a demand, is entirely subjective. So we can't say what increases or decreases it, because it's subjective. It's human, right? Humans are not...

[00:50:17] John Carvalho: So, very simply, supply is the subjective value of the seller and demand is the subjective value of the buyer?

[00:50:26] Eric Voskuil: Right. And if you look at trade, I use the word trade because there isn't a buyer and a seller, they're two people trading. They're symmetrical, right? So Marshall comes along, who's a later economist, right? And he's writing textbooks for Economics 101. And he develops the graphs, right, like the supply-demand graph, the intersection, the cross-cutting scissors, he calls them. And he comes up with these terms like supply and demand that get very formalized. And people start thinking of these things as two different things, right? They're not. They're trading. People are just swapping stuff. So that's how this idea gets lost and then misused. And even Menger, to a certain extent, I will do this.

[00:51:10] Menger does this. Everybody does this. They get casual with terminology, right? And they'll occasionally refer to supply in a quantity sense. But I'll give you- let me see, give you an example of this. So to understand how production of dollars, which is a quantitative thing, right, produces price inflation, there's some piece missing, right? If it's not quantity, what is it? And now, many people, I think, will recognize that if you printed- say we went out and the US printed $5 trillion. I think there's somewhere around 5.8, some in the world, there used to be 3.

[00:51:57] We doubled the number of dollars, but we just put it in a vault somewhere. We just put it in a vault somewhere. We put it in the back of a room, and nobody even knew about it. What's the effect on price inflation? None, right? Absolutely none. It's

[00:52:11] John Carvalho: The distribution that would affect it.

[00:52:13] Eric Voskuil: But the distribution is human, right? And this is where we get to demand. So quantity, absolutely, trivially proven, right, is not what determines price inflation. It's not quantity. It has to be something else. And it's not just, OK, we took it and we threw it into the air. And also now, because of the quantity, right? But that's not enough either, OK, because supply is human. So let's go back to the idea of monopoly control, right? If I can produce dollars, and nobody else can produce dollars legally, and let's assume nobody does, right?

[00:52:53] It's too dangerous. So I produce dollars, I produce a $100 note at $0.20 today, purchasing power of $0.20 today. So I've got a $99.80 seigniorage revenue on every $100 note that I produce.

[00:53:15] And I want to buy some tanks. Say I want to buy 10,000 Abrams tanks, and that's going to cost $100 billion or something. And so I print that money, and I spend it. So when I spend it, to buy all the parts, to hire all the people, to do all the stuff, what is my demand for that money? $0.20 per $100, right? That's what it costs me. That's what I have to surrender to get it. That's my seller's demand. That's my demand for the money.

[00:53:46] So that is where seigniorage, that is where price inflation comes from, right? If I did not have that privilege, seigniorage, right, of producing $100 bills at $0.20, they would cost me $100, right? So let's say I could only produce, nobody could produce $100 because they were so complex and difficult, right? Anybody could produce $100 bills, but they cost $100, right? Maybe they cost $99, and then $1 is my margin, or they cost $90, and $10 is my cost of capital. Still, that's market price, just like Bitcoin production, right?

[00:54:29] So I produce that $100 billion of dollars by doing what? By mining the dollars. I had to expend $100 billion in my own time and capital to produce those dollars. Now, do you think I might be a little bit more reserved in my spending of those $100 billion than if they cost me $0.20 each? That's my demand changing. If I can produce them into the future forever at $0.20, my demand for them is no more than $0.20. That's the floor on my demand. I could have expressed a higher demand.

[00:55:08] If I can get more, I'll take more. But if I can only get $0.20, I will. And that's how these units get produced, down to the point where they're not in circulation anymore, because that's actually what's happened. Spending the $100 note someday will be worth $0.25, and then it'll be worth $0.20, and then it'll go out of circulation. The floor on my value is $0.20. So that demand is a function of my cost to produce. And my cost to produce, my profit on production, is a consequence of the anti-counterfeit laws.

[00:55:39] So it sounds really obscure. Oh, the anti-counterfeit laws are the basis of all this. But it is. State money has the privilege of prohibiting competition in production, and therefore, can extract a premium. And so when states started printing paper to receive gold, those were certificates. The paper wasn't supposed to be worth the $33, wasn't supposed to be worth the ounce of gold. It was a certificate for the gold. But then when you remove the gold, the dollars kept trading at that price point. But they only cost $0.20 to make, instead of 33 ounces of gold to make.

[00:56:17] That's where we got price inflation. If everybody else could have made those bills, then there would have been a lot of them, and they would have been worth $0.20 each. But it still would have functioned. It still would have been viable money, technically. It just wouldn't be very portable. It wouldn't be very useful. So there's this theory that only states could produce fiat money essentially because the anti-counterfeit laws are necessary for the paper money, for fiat money, to function. Because if everybody produced it, it would go to zero.

[00:56:56] The real reason is the state wants to earn that privilege, that huge issuance privilege. So along comes Bitcoin, a money with no commodity value whatsoever, first money in history, that has no commodity value like gold, but still has a cost to produce and still has a market price for production. That was not envisioned. Nobody had imagined that until it happened. And so for the first time ever, we have a money that's a pure money. It's not a commodity. It doesn't have any material value aside from its moneyness.

[00:57:34] But it doesn't require anti-counterfeit laws to operate, which is why it's interesting and confuses people when I say that Bitcoin is fiat. Fiat is money that is not a commodity money. It has no use value in the economic terms. It has no use value. Just like dollars don't have material use value, they're fiat. That's the only criteria for being fiat. It's just that prior to Bitcoin, only state money was envisioned to be possible to be fiat, state money that was declared to be money. But the declaration is not the important part.

[00:58:14] It's the fact that it's protected by any counterfeit laws. So Bitcoin being produced at market price is not price inflationary. Gold produced at market price is not price inflationary. On the other hand, Bitcoin is subject to monopoly control, and so is gold. And as Cantillon observes, gold could be inflationary. As the Romans observed, as the Queen of England observed, gold can be inflationary if you have monopoly control over it. And Bitcoin certainly can be inflationary if you have majority hash power control over it. You can charge, even if there's no new issuance, you can charge demurrage on every transaction, making it impossible for people to hold without losing value.

[00:59:01] You can issue yourself new money anytime somebody exchanges the money and effectively make it inflationary. So it's the monopoly control that makes it inflationary. It is not the creation of new units. And that depends on an understanding of supply. And it's so critically important, and yet people will still say, you're just talking semantics. Supply is just a quantity. I'm talking the absolutely essential true meaning economically of these concepts, and you don't get it.

[00:59:37] John Carvalho: So I want to ask another maybe truly nuanced question. You described all this stuff when you described money in Bitcoin and dollars, and you mentioned the quote unquote cost to produce, but you don't refer to money as a product. You refer to it as money.

[00:59:59] Yeah, so in that sense, a little bit off topic, I kind of have jumbled notes here, but people talk about the divisibility of Bitcoin. A lot of Bitcoiners think that it's infinitely divisible, and that would affect nothing. It would just add more decimal places. I have a much different view on this. I think that you can only add quantity of units because of the way Bitcoin works, and thus you only can offer monetary inflation. And then even when I point that out, somebody like Adam Back or such will say, well, that doesn't matter either because it would be evenly distributed.

[01:00:39] And I said, well, that would depend on the design, right? It would depend on how they implemented the increase. I

[01:00:45] Eric Voskuil: Mean, I understand what you're saying, but I need a little bit of context here. When you're talking about you can only divide or you can only add, what are you referring to? Particle changes? Consensus changes? What are you referring

[01:00:58] John Carvalho: To? In the abstract, whatever it would require, but what I'm referring to is there are 2.1 quadrillion units. What problem are you trying

[01:01:06] Eric Voskuil: To solve? What problem is being solved by that? I truly don't understand what problem is being solved. I don't think

[01:01:11] John Carvalho: Bitcoin needs to be divided more. I wanted to explore, it's a nuance you made me think about that I've tried in the past. And it's simply that I think that people don't think hardly enough about what the implications would be even in a fair monetary inflation of Bitcoin. In other words, we talked about this a little bit in the past where I used to think that you could run out of UTXOs, for example. But in other words, the overall cost of UTXO would change and be affected if you could make more UTXOs out of more units.

[01:01:46] In other words, say one Satoshi or one base unit was reached $1. And then everybody would say, oh, we need more divisibility. It's already $1. Now, I don't think that will actually ever happen for other reasons. But they will, they say this, and then they'll say, oh, it's no problem. We could add more decimal places. And I say, well, you would you could multiply the quantity of units, and then you get more precision. But if you multiply, yeah, but if you do this, you have to tell me how you plan to do this.

[01:02:14] Because if you plan to do it through mining, that's one way to do it. If you try to just multiply everybody's balance by 10, that's another way to do it. And does this actually have any economic effect that we would want to consider? I don't

[01:02:30] Eric Voskuil: Need you to explain this aspect anymore, but I'm still a little bit fuzzy on what's the question being answered by this. But I think I can respond anyway or comment anyway on what you're suggesting by putting it in a context that I have heard, and maybe it's the same thing. So all the discussion I gave about inflation, supply, demand, monopoly, seigniorage, Cantillon, monopoly control, there's this other aspect that Bitcoin will go, yeah, but this. And it's worth considering that despite the fact that Bitcoin is produced at a market price, which means every unit that is produced is not price inflationary, it is also the case that, to just simplify the question, it's also the case that at some point, there'll be no more production.

[01:03:36] There's also this tailing off of production, that's more complicated to contemplate. So just contemplate the point where there is no more production. It's not like gold, where you can produce more when the price goes up, and it keeps the price stable, keeps the market price, the market price, and it's not inflationary. It's deflationary. I've written about this, too. In theory, so here's the theory. There's only, and this goes straight to the maximism thing when we bring Max back into this, if I say Max, Vlad, the idea that if you could only have one money in the universe, and it's Bitcoin, BTC, you have BTC, and at some point, no more is being produced.

[01:04:29] But there's demand for money, because money is useful, so people need some. And increasing demand means increasing demand on the supply and demand actually means, when it comes to money, means both parties. Somebody wants money, and somebody wants to give it up less. Demand increasing affects both the seller and the buyer. Sellers sell for more, and buyers buy for more. When demand is increasing, and vice versa. So demand is the only thing that determines the price of anything. And when it comes to money, demand is essentially a proxy for the price.

[01:05:07] So when demand is increasing for the money, the price is increasing. We're having price deflation in the money, because no more is being produced, unlike gold. And that is unique to Bitcoin. No more can be produced. Whereas presumably, any tangible commodity could be produced forever. So doesn't that mean that Bitcoin is deflationary, which means as demand increases, all the hodlers are going to continue to get rich? Now, I pointed out in the very beginning that if something goes from zero to anything, it's infinite growth. And so that is not itself, because that's necessary, it's not evidence of this phenomenon.

[01:05:55] It was going to go from zero to something before it became a stable money, and we may or may not be there. I don't know. But that is not evidence of the fact that price will go up forever, because ultimately, there's no more production. So if you accept the idea that there can be only one coin, and everybody just uses that coin as the only one, the only money, because somehow they have to, then you've accepted this idea that you will get rich by holding the money.

[01:06:36] And of course, those riches have to come from somebody producing something. It's not free. So the question is, interestingly, where does that magic come from?

[01:06:47] So when we talked about what's the maxi premise, I had some lengthy conversations with the quintessential maxi, who shall remain nameless years ago. And when this term was starting to get used the way it's been used, somebody that I knew quite well, or I had known for some time, and we respected economically and stuff. And I was able to get down to the point where the idea behind this maxi stuff was this assumption that if there's one coin, my value is going up. It was the NGU premise.

[01:07:25] But it's all based on this assumption that there's one coin. And I'll talk more about this later, but that's a big assumption. It's never been the case, probably never will be the case with any money, nevertheless, Bitcoin. But the assumption that there is no monetary inflation, therefore, no ability to produce more, therefore, you have constantly rising demand is the assumption. And it's not a valid assumption. It's never been a valid assumption. People want it to be a valid assumption. And that's where so much conflict comes from.

[01:08:06] And I've never accepted that.

[01:08:08] John Carvalho: There have never been more monies than since Bitcoin was created.

[01:08:11] Eric Voskuil: Right. I mean, the primary money, the primary alternative to Bitcoin presently is government money. It clearly is. People in Bitcoin are saying, don't use your Bitcoin, use your government money. OK, there's your alternative. It's what's showing that your argument is not true. So there's another whole aspect of this, which I pointed out a long time ago, which was that Bitcoin is unique in two ways. One is this aspect of, I talked before about, I mean, it could be a lot of ways, but two big ways, where as it gets more demanded, it gets harder to produce.

[01:08:50] That's not true of anything else. So you have this inversion where it's the cost of production that changes, not the quantity of production that changes when you have changes in demand. But the flip side of that is that when demand is rising, which is what's causing this price to increase, presumably, fees are rising. And we've seen that. I wrote these things up before we had these giant fees that have come and gone. But clearly, when we get to a certain demand level, Bitcoin is not usable for certain level size transactions.

[01:09:29] And it's always been the case, right? Microtransactions got wiped out pretty quickly. And as the demand for Bitcoin rises, the cost of using it rises, which is a negative feedback loop. So that negative feedback loop absolutely limits the utility, I mean, the price, ultimately, of any single chain, because it will become cost prohibitive for most, if not all scenarios at some point, right? It has to stop going up. So what happens in those scenarios, right, where it's becoming cost prohibitive to use, but there's rising demand? People use other things.

[01:10:20] So if we take the maxi premise, and we just force them to all use BTC, what do they do? Well, the argument would be they use Lightning, OK? We can talk about that. Or sidechains. I would argue they just all use $1, right? Or that's under the premise that we force them to only use one coin, meaning Bitcoin-like thing. And if they don't use that, they're going to use dollars, euros, rand, yuan, RMB, whatever. But that assumption doesn't hold. We don't force them to use just one.

[01:10:58] We never have. We can't. And so they use Litecoin, or they use Monero, or whatever, right? Setting aside the different features, you can make this kind of theoretical discussion with Bitcoin being BTC, BTC-1, which is exactly the same, except slight change to the mining algorithm, right? BTC-2, 3, 4, 5. You could have an infinite number of these. And I've had smart people tell me, well, if we did that, then it would be worthless. Because it would be infinite supply, right? And people actually think that.

[01:11:34] Some people actually think that. But we can't prohibit it. So what it implies is we can't prohibit Bitcoin from going to zero, which is stupid, right? So there's something wrong with that theory. What's wrong with that theory, just like everything else, is Bitcoin has to be produced to have value. It has a cost to be produced, just like gold. It's like silver, right? So if nobody's mining it, it's not a money. It's not a chain, right? And the reason nobody's mining it is because nobody's willing to pay fees on it because nobody's demanding it.

[01:12:09] So when demand overflows one chain, it flows into another chain. It causes fees. It causes mining. It causes security. It causes an alternative. And that exists. And we've seen that when fees got really high in Bitcoin. They flow over to Litecoin or some other coins. Now, I have no real interest in things like Tether or stablecoins or tokens, any of that shit, right? So just ignore all that because that, to me, is more like dollars, right? It's tokenization. It requires a, what do you call it, a custodian.

[01:12:48] It doesn't have the security model of Bitcoin. So if we're interested in something that does what Bitcoin does, which allows people to have a market money as long as they can keep it from being monopolized by state mining, how does this actually work? Well, that's how it works. It already works that way. It's always worked that way since the very beginning. When demand causes the cost to use to rise to the point where it's not usable for certain scenarios, that demand overflows into other chains. That doesn't preclude sidechains or lightning, right?

[01:13:27] That can also happen. But as we've seen, it still will push fees, and it still will get expensive, and it still will overflow into other chains. So if that's going to happen— Are you OK with thinking,

[01:13:42] John Carvalho: You described all the blockchains as pretty much a spectrum. And I'm going to guess you'll also be OK with saying, well, all of the money solutions could be put on that spectrum in some way, even if maybe it folded into subcategories and such, depending on your use case and what problems you're trying to solve. If all of that is sort of accurate, would you then be OK with me saying that the different monies compete?

[01:14:09] Eric Voskuil: Yeah, monies compete, sure.

[01:14:11] John Carvalho: I've tried talking with you about this before, and I didn't quite get this far. And you wouldn't accept the competition aspect.

[01:14:20] Eric Voskuil: So first of all, people always want to— I'm not saying you're doing this, but people always want to kind of put me into, like, a category, right? Like, you know—

[01:14:32] John Carvalho: Not my goal. I'm just trying to understand and be able to help other people understand. I

[01:14:37] Eric Voskuil: Know. But when you say, like, are you OK with, right? I want people to understand. It just kind of triggers my spidey sense, and I go, like, OK, it's not about what I approve, right? I try very hard, as you guys probably know, to not make—

[01:14:53] John Carvalho: You could replace it with, is it rational to say?

[01:14:56] Eric Voskuil: Right, right. I try not to make predictions, and I try not to tell people what they should do. I try to explain how things work the best I can. And what I'm explaining here is how it actually works. How it actually works is things get too expensive, they move somewhere else. That's a basic economic principle, and we can observe it clearly in Bitcoin, right? And one of those other places is similar altcoins. Litecoin, for example. I just want to use as an example, there's no special reason, right?

[01:15:31] And I'm not even talking about other features. There's feature reasons why that might happen, like Monero, for example. But setting all that aside, just let's assume there were identical feature-wise, security-wise, except for, like, hash rate, right? We're talking about high hash rate change because there's high demand, high fees, high cost to use, right? There's your high security chain. There's your deep vault, right? But then you want your kind of less secure money, which maybe you keep in your house, and then maybe your less secure money, which you keep in your wallet, which is easier to spend, lower amounts, right?

[01:16:05] Well, you got to have lower fees, right? So these things spill over into other chains. That's a natural progression, and it's a natural analogy to how people secure things, right? You're going to pay less to secure less. So on the other hand, to answer your question more specifically, you asked about other stuff, right? And I'm like, anything that has properties like money presumably can compete with Bitcoin, even if it's not the same. Like, for example, Tether, dollar token, dollars, euros, gold, they all in some way compete with Bitcoin.

[01:16:42] It depends on what scenario the person has in mind. And what Bitcoiners presumably want is more of those scenarios being Bitcoin and less of them being state money. Far as I'm concerned, if people are happy with their state money, I don't care. I really don't. To me, this is to provide a choice for people to do what they prefer, not for me to tell them what they've got to do. So it's a market. It's up to us to provide a better alternative in some scenarios for people to use Bitcoin where it provides value to them.

[01:17:19] And I look at where it provides value to them, and that, to me, is in its ability to do things that are not allowed when you're using state money, or they're expensive when you're using state money. One is having the money means you pay the inflation tax. You have state money. Having gold, you don't pay the inflation tax. OK, great. Speculation, let's just get this out right up front. I'm not talking about speculation. Money does not earn. So if you're holding gold, or if you're holding Bitcoin, if you're holding dollars or euros, whatever, as a speculation, that's fine.

[01:17:58] Go ahead, do whatever you want. But I operate always under the assumption that money doesn't earn, it doesn't gain, it doesn't inherently gain or lose. It's neutral. A good money is neutral. So we talked before about going from zero to something, and yes, that happens. We know that we talked a lot about inflation and why seigniorage leads to increasing supply and therefore decreasing purchasing power. Those are all true things. But none of this, to me, has anything to do with speculation on coin. It's not a speculation to hold gold over dollars because you know that dollars are produced under monopoly protection, and gold is not.

[01:18:44] You will hold value, or you lose value with dollars. Dollars being more liquid has certain advantages, so you'll end up using both. Bitcoin is more liquid in certain ways than gold, and it doesn't suffer the dollar tax. Unless you feel compelled to pay capital gains tax. You may be paying some of the dollar tax, right? So Bitcoin provides benefits. Bitcoin is a money whose value proposition or which value proposition is that it can avoid state controls, but it can only avoid state controls to the extent that people are willing to ignore them.

[01:19:26] And some people aren't. I don't. I pay my taxes. But there are people in many parts of the world who would rather take the risk of ignoring state controls, currency controls, or taxes to use Bitcoin to- I don't know. I would use the people in Venezuela or Myanmar funding their revolution with Bitcoin and ghost guns. Great. That may be worth it to them to do that. And that's, to me, the main reason we do this. I certainly haven't worked for 10, 11 years on Bitcoin to pump sailors' bags.

[01:20:10] I don't give a shit, or anybody else in the West. We just don't really need it, at least not to the extent that some other people do. So there's all these other things that can compete with it for people who maybe don't need it, like maybe there's a competitive speculative coin, or you can do smart contracts, which have no security, ultimately, because they require custodial control, or you use dollars because it's just easier. Those are all competitive. But I'm only concerned, personally, in competing with the things that Bitcoin has value that other things in scenarios where others don't.

[01:20:53] Permissionless money. That's where all these other things fall apart. And that's why Bitcoin exists.

[01:21:01] John Carvalho: The reason why I want to establish that competitive dynamic across money is because- a couple reasons. I find it to be a useful device in explaining the difference between what might be a scaling method for Bitcoin and what might not be. For example, people like, including Blockstream, like to call liquid a layer, and thus it scales Bitcoin and such. And I like to point out that it's almost indistinguishable from any other altcoin, other than the consensus mechanism, in that it's simply a federation holding a peg to their own shitcoin to Bitcoin.

[01:21:38] And thus, it can't be scaling Bitcoin because it's all transactions that will never happen on Bitcoin, and thus it's competitive to Bitcoin. And this is a way to reason about explaining to somebody how liquid is just shit.

[01:21:50] Eric Voskuil: And the fact it's a security model is not Bitcoin, and doesn't therefore provide the advantages that I was just talking about, which is why I don't care about it. It might be useful for some people, again, but it's not why I'm working on Bitcoin. And so one is that there's an underlying question, right? Is the objective, I mean, Bitcoin doesn't have an objective, right? But for people that work on Bitcoin, like me, what's my objective? What's my objective to make sure that everybody in the world uses Bitcoin?

[01:22:23] Absolutely not. There's no reason. It's not necessary. It would be a lousy requirement to place on the system. So why does the system exist? Who does it help? And what can it do that other things can't do, right? People talk about, say, the unbanked, right? I'm not a big proponent of the unbanked theory. I've been to 90 countries, many of them many times, and sometimes motorcycle, driving around. And Africa, for example, like different countries. I never encountered a situation where there were lacking banks, even in [unclear: towns] That had nothing but dirt roads.

[01:23:07] So there's a nice shiny new bank there. It's not that they can't get them. They don't want them, right? Because they steal their money. And so in Zimbabwe, I might have talked to a butcher. He was actually working still as a tour guide, but he took me to his house, which he was building himself, and he had a few cows, and he was working on building his own business to be a butcher. And he really understood how money worked better than most people in the West. And he understood, they were on the... The fourth had just failed.

[01:23:41] They were working on the, what was it? It's not called the 5th, but it was the bond notes which were coming out, one to one with the US dollar. But they were still trading, and all the ATMs were empty. All people were lined up at the banks trying to get their $20 daily allotment of their own money out of their own accounts. And I'm like, so I'm standing there in the guy's house and in his driveway, and it's still dirt floor. He's still putting his roof on and everything, and he's got a couple cows running around.

[01:24:10] And I'm like, why do people put their money in the banks? Why don't you just not do it? He said, oh, direct deposit is required by law. I'm like, yeah, but you're going to run a butcher shop, and you're going to work for yourself. So you won't have to put your money. You just have a cash business. He said, no, no, no. They come in, and they inspect you. And if they think you're not depositing your earnings, you're screwed. I said, so you're going to do it?

[01:24:32] He said, yeah. So even though he understood how it worked, they all do it. So are they unbanked? Fuck no. They don't want to be banked because that's how the state robs them again and again and again and again. And the way they robbed the fourth was just absolutely ingenious, like Mugabe. And so he just took, waited until people started putting their dollars, euros, and rands in the local banks after the failure of the third. And then maybe it was this. Yeah, after the. And then they connected them up to the financial system.

[01:25:08] They opened up banks. The local banks opened up banks in Europe, and it was all working good again. And they had credit cards. And then Mugabe went to the local banks and said, yep, I'll take all those European accounts. Thank you. Took control of all the European bank accounts that had the dollars, the euros, and the rands and international access and left the local banks begging him for the depositor's money from the European banks, which dried up pretty quickly because he spent it all. And that's why people were waiting in lines at ATMs, waiting in lines at the teller counters when the ATMs were all empty all across town.

[01:25:46] So people don't want that. So I look at these scenarios like, oh, we need to make sure. It's like a technology problem. Is there a technology problem where people can't get banks? No. Is there a business problem? No. It's a state problem.

[01:26:01] And so is there a gambling problem? Do we have a lack of places to gamble? No, there's lots of places you can gamble. So I don't really care about Bitcoin as a speculative mechanism either.

[01:26:15] There are currency controls that are onerous and inflation taxes that are onerous that prevent people from saving in money, having money, transferring money the way they want to. And in some cases, that's extremely oppressive, keeps people poor. And Bitcoin is a lifeline to some of those people. And that's who I work for, basically. And so I think the worst bug you can have in a software system is a requirements bug. You go out, you design this whole thing, you realize you built the wrong thing. And that's most of what I see in the whole Bitcoin ecosystem is just there's a requirements bug.

[01:27:00] They're building stuff that doesn't make sense.

[01:27:04] John Carvalho: And I had a second half of the competition thing being relevant, which was, you touched on it briefly as well, which is this, when people talk about scaling methods for Bitcoin, particularly adding complexity and new softworks and things like this, and the kind of latest champion being UTXO sharing or many-party UTXO sharing, I like to point out this competitive aspect because I say, look at how much complexity and fragility people have to put up with to use Lightning, which is just two parties, which makes it so much more manageable in a network than when you start going to three or more.

[01:27:45] And I could tolerate all of the interest and things when it was two parties, but then when you turn it into three or more and you have this game and you have all these other network dynamics you have to deal with, coordination, et cetera, I just think they're way off base. They're just totally disregarding that. People won't tolerate that. They will just use something else. Why do they think the demand to use Bitcoin would be so high that people would tolerate waiting in line and the risk of not being able to get in line or afford a place in line and deal with just more complexity for holding and sending Bitcoin when they could just use something else?

[01:28:29] There are many things that have this, as you mentioned, speculative quality. And many times, if that's your goal, you're probably better off choosing something other than Bitcoin because you could get a much higher risk reward elsewhere, most likely. So yeah, I also like to point out the competition aspect between all of these things because not only is it possible that you're going to make a layer that competes with Bitcoin, but you're going to make something that's so unusable that people will now have to compare it to the alternatives.

[01:29:00] And so I don't think that core developers weigh these kinds of considerations when they are aggressive in promoting things like covenants, et cetera.

[01:29:11] Eric Voskuil: Yeah. I mean, when Lightning was first, I don't know if it was the first public proposal, but I remember I was at Scaling Bitcoin Hong Kong, and I saw the early presentations on it. It might have been the first. There was a breakout room, and we talked about, right off the bat, people were hitting on the limitations and issues and stuff. And it wasn't that they weren't considered. All the issues that have been encountered were understood. They were brought up by smart people in the room right there.

[01:29:47] And I mean, maybe had already been discussed in other places online or something. But they decided to proceed anyway. I mean, maybe because it felt like it was worth trying it out, a reasonable trade-off, right? But a lot of hype, a lot of venture money came in.

[01:30:09] And it was a fait accompli, right? This is it. This is going to work. But I never did any work on it or any other sidechain. This is why I don't comment on it too much because I'm fairly ignorant about it, the technical details, because I never worked on it. But the reason I never worked on it was because these issues to me seemed ultimately prohibitive. And they weren't going to really solve any problem that I was seeing. They were going to just push the problem, and these would just get pushed in the chain anyway.

[01:30:51] But the same is true. I've never voted any of that. I've never supported any of that. The arguments I see from Luke and his followers don't make any sense to me. The fact that sinking Bitcoin core is getting slower and slower, as you probably know, is, to me, a consequence of a lousy implementation, which is the consequence of Satoshi shipping a prototype. And it being complex enough and fragile enough that nobody dared change it, except us, right? So even the language ports and the altcoin ports are still based on the same architecture.

[01:31:33] So we're trying to change that. OK, so the smaller block thing, to me, never made any sense. It's getting faster and faster to sink the chain, or should say, cheaper and cheaper. Not getting faster on the same hardware, but the hardware is getting cheaper and cheaper, and it's getting faster on current hardware. So we're demonstrating that, and I hope to be able to ship that pretty soon this year. So then there's the block size increase aspect of it, which is there's an aspect of the security model which has to do with what size of an operation you have to run in order to validate, in order to use Bitcoin.

[01:32:13] I think the core developers, I'm not talking about Bitcoin core, but including people like me, have generally stood against just arbitrarily increasing block size, because they see that it's not going to achieve anything in the long run. Even if it was fine for now, even if you took, if Bitcoin successfully ships, and we show that it's getting cheaper and cheaper, and so you proportionally have a fork to continue to continuously increase the size so that sync time stays fairly constant across hardware, even that is not going to solve the problem.

[01:32:59] Because the problem is a lack of really understanding some of the stuff we talked about earlier. It's really that...

[01:33:09] John Carvalho: This is one you haven't fully sold me on yet. I still have a little belief in the idea of a sweet spot. Where basically, you know, you acknowledged earlier that maybe not everybody needs Bitcoin, and not everybody, you know, Bitcoin maximalism and hyper Bitcoinization in these concepts. I also think that their ideals and extremes that you can't actually reach. But that doesn't mean that those aren't directions worth walking towards. All ideals. And so in this case, what if the proportion of humans that wants to use Bitcoin?

[01:33:47] Is slightly above, you know, or, you know, or within the block size that is reasonable, but as we talked earlier, well, you mentioned earlier that the prices are exclusive as well. And the cost of running a node is exclusive and centralizing the cost of sending a transaction is exclusive and centralizing as well. And so if people can't afford to send transactions, but they can afford to run a node. Then why wouldn't we, you know, if we could identify somehow that there's a demographic of people being excluded, that would be included.

[01:34:24] Eric Voskuil: But why would we not?

[01:34:26] That's my point. Nobody's excluded. They just use a different chain. They use Litecoin.

[01:34:30] John Carvalho: Well, excluded from... But that's the premise here. The premise here is maximizing, right? The premise here is maximizing. Exactly. Exactly. But I think you'd find that most engineers, most Bitcoin core devs would agree with the idea of maximizing throughput,

[01:34:46] Eric Voskuil: Users. But it's not a maximization problem, right? It's just a trade-off. It's a straight trade-off. You're trading off fees and time and cost, right? So fees are a cost, and node size and resources is a cost. It's really ability to hide, right? The cost of you hiding your illegal operations and the cost of you getting your transactions through the system, those are the costs of using Bitcoin. And as those costs increase, people are going to go somewhere else. And where do we want them to go?

[01:35:27] I want them to keep using Bitcoin, right? But they're not going to keep using BTC if it's too expensive. They're going to go to BTC1 or BTC2 because fewer people are using it. This is

[01:35:37] John Carvalho: Where you lose most Bitcoiners because they're trying to say everything is a shitcoin, right? It's already

[01:35:43] Eric Voskuil: The case. It already happens. It's already done. I don't even need to prove it. It already happens. So I'm just pointing out what is.

[01:35:53] John Carvalho: I'm not pointing out... I'm pointing out that many Bitcoiners still believe in designing for that outcome. What's that? I think that many Bitcoiners still believe in designing for the outcome of maximizing the throughput.

[01:36:05] Eric Voskuil: Sure. And maximizing the throughput on any given chain is a noble goal. It's what I work on. I've been working on it for years, right? I've been working on making a single node faster and easier to maintain. Do you

[01:36:22] John Carvalho: Have an argument against that if, say, fees were $1,000 per transaction for two years and that raising the block size would decrease, it would basically increase the throughput and allow more people to

[01:36:35] Eric Voskuil: Use it? It would trade off the throughput. And big core developers know this. They've argued this. Most of them accept this, right? So it's not a controversial position that I'm holding. What I'm pointing out is that their resolution to that problem has been sidechaining. And I haven't really seen that take off.

[01:36:58] John Carvalho: I think your take on that is outdated. Nobody talks about sidechains anymore, except weirdo drivechain people.

[01:37:04] Eric Voskuil: I put lightning in the same category, all right? Layering.

[01:37:06] John Carvalho: You would define lightning as a sidechain.

[01:37:08] Eric Voskuil: No, I should say layering, OK? Layering is a trade off. It decreases security and increases complexity in exchange for increased throughput. That is one approach. It's a valid approach. My argument would

[01:37:23] John Carvalho: Be that's much harder to measure and allocate than a block size increase.

[01:37:28] Eric Voskuil: I'm not saying about, I'm not making any argument about whether it's harder to measure or allocate. I'm just saying that it exists. It's legitimate, right? Like, there's liquid, there's lightning, there's layering on BTC, there's layering on other chains. But I'm pointing out that those things, what I said earlier, was those things don't seem to have taken off. Presumably, there's reasons for that. Those trade-offs are real. They're not inconsequential trade-offs, which you have pointed out, I think, fairly. And what I'm pointing out is that since before those even existed, there has always been other chains.

[01:38:05] And there could be a series of chains that are exactly the same rules as BTC, with the exception of a mining algorithm difference, right? So that already happens. Nobody that I know of has put any energy, any whatsoever. Nobody has put energy into an ecosystem that looks like that. Yet, it's still the dominant ecosystem. That ought to tell you something, because the decade of work on layering has not produced anything close to the level of success. We haven't quite

[01:38:41] John Carvalho: Come up with BTC-1, BTC-2, though. What we have is BTC-1, huge gap, and then the rest. Lightning.

[01:38:48] Eric Voskuil: I mean, sorry, Litecoin, right? They have BTC. But the

[01:38:51] John Carvalho: Gap in security is so far.

[01:38:54] Eric Voskuil: I don't know. When was the last somebody double-spend on Litecoin? When was the last double-spend on Litecoin?

[01:39:00] John Carvalho: Well, I will concede, and I was also going to raise the point that, how do you explain that? Is it just that the blockchain design is so good that most blockchains don't get attacked?

[01:39:13] Eric Voskuil: It's just a simple economic thing. It's not worth the cost of the attack, right? If you do smaller sized transactions, and you wait long enough to confirm them, then it's just too expensive to attack. Bitcoin hasn't always had the hash rate it has, right? But since I've been working on it, I mean, I don't know how comparable between Bitcoin and other chains, but the hash rate on Bitcoin has gone up quite a bit in 10 years, right? But we thought it was secure 10 years ago. This argument doesn't really make sense.

[01:39:46] It's a question of how much security is required for the level of transacting that you're doing. And what I'm pointing out is that for years, people have worked on layering and not achieved much. I mean, Lightning has some adoption, and I don't really pay much attention to it, but it doesn't seem that people are very happy with it overall. And there's Liquid, which I think is a ghost town, from what I have read. Again, I don't use it. And what else? I don't know. And I'm setting aside all the tokenization, all that crap.

[01:40:16] There's these centralized things. So when it comes to real Bitcoin, maybe layers on BTC, where's the volume? Well, there's some on Lightning. No question. Lightning gets used. But the problem that you're raising is that that's not working. And what I'm pointing out is, even before they existed, there were already alternatives that were working and continue to work with nobody putting any effort into a multi-chain ecosystem.

[01:40:46] John Carvalho: What I'm trying to distill here and understand is the difference between where I have tolerance for block size increases and you have none. And I'm trying to understand your rationale on that. I think there's some gain to it.

[01:40:59] Eric Voskuil: I didn't fight the last block size increase. I wasn't up in arms about 4x increase. So all I noticed was that it... Well, I'm not asking

[01:41:08] John Carvalho: About what you're fighting. I'm asking about the understanding and the dynamics and the logic behind it. Like, in other words... My point is simple. It can't solve the problem. Do you think that that was a problem? That was a waste of time to raise the block size?

[01:41:19] Eric Voskuil: Yeah. And there's a lot of people that are having second thoughts about it now, right? And I just... Well, I mean, for a few

[01:41:25] John Carvalho: Weeks, we've had low fees, but most of the time... I would say the average block size has been much over one megabyte,

[01:41:31] Eric Voskuil: Right? No, no, I wasn't talking about the low fees. I was just talking about the cheap spam, which is also a context aspect of low fees. And I don't really use the term spam. I think any transaction that's valid is legitimate. But the point is, it solved that aspect of it. It solved a non-problem. They were under pressure. They didn't want to lose the big war. So they gave it a dual block size increase in conjunction with the other stuff that was happening, right? Which was unrelated.

[01:41:56] We also had fee

[01:41:57] John Carvalho: Pressure at the time. We had $25 Bitcoin fees, and that was the first time we had it, right?

[01:42:01] Eric Voskuil: And we still have, right? So, again, we came right back to having that. And it didn't solve the problem, right? Well, my point

[01:42:11] John Carvalho: Would be that, just what you said, if we had $25 fees when the block size was one megabyte, and we reached it again when the block size was up to four megabytes, then we did something that had an impact, because those blocks would have only been one megabyte.

[01:42:25] Eric Voskuil: No, no. It's just fewer people would have... Fewer scenarios would have... The scenarios that made it onto the chain would not have, right? If $25 was the limit that people were willing to pay, they still would have paid only up to $25. It's all the stuff that wasn't worth $25 that would have not have made it onto the chain. And largely, that was inscriptions and other shit, right? So that's why people were having second thoughts about it, because basically, all we did was enable that. That's one way to look at it, right?

[01:42:52] And again, my point was, I didn't take a stance against SegWit. There's some stupid shit about SegWit implementation that I don't like, but it has nothing to do with the concepts. And I didn't take a stance against that attempt to make a block size increase, but I have said, and I do believe, that making that increase delayed what I want to achieve, which is fast notes, right? If you increase 4x, you're delaying a couple of years the performance that I would like to achieve. But it'll get there.

[01:43:33] But if you do it perpetually, it'll never get there. It'll never have truly fast notes. We'll have these...

[01:43:38] John Carvalho: Well, for what it's worth, that's not how I look at it. I look at all change for Bitcoin or proposal for change as something that should be driven by the market, not the engineers.

[01:43:49] Eric Voskuil: Nobody controls it. I'm not saying the engineers control it. I'm just saying that if it keeps happening, we won't get there.

[01:43:55] John Carvalho: I'm not commenting on what you're saying. I'm saying in general that the culture of Bitcoin Core and Core developers and protocol developers tends to be that they assign certain solutions, and they say with amongst themselves that they've reached some sort of consensus, and thus it's ready to impose upon the rest of the user

[01:44:18] Eric Voskuil: Base. Well, again, that's one of the reasons why I don't work on it. I don't work on that application. I don't like the design, and I don't like the fact that it's a singularity in the community.

[01:44:38] I've always taken the position that the purpose of Bitcoin is for people to do what they want with their own money.

[01:44:48] People who mine a shitcoin or people who make their big block coin, even if it's Bram Cohen did his Chia thing, and it was based on proof of space and time, and I critiqued the design and the objectives.

[01:45:16] I critiqued in that the explanations were incorrect, and they eventually accepted that, but that's just one of many examples where I like to explain to people how things work so they can make informed decisions and so that I can learn. I learn by doing it, but I always support people's right to do what they want with their own money. And if that means forking, go for it. You fork yourself off, do what you want. You want to activate? Absolutely. Have at it. Do it all by yourself.

[01:45:49] You want to start a new coin? You want to make a sidechain? You want to do lightning? I don't care. I'm not going to work on all of it, and I don't care if you want to make blocks bigger. And if enough people get together that use BTC, and they say we want 10 gig blocks, and every single person does it, and nobody is mining Bitcoin or BTC anymore because they've all moved to this other coin, that just means the old one dies, and that's what people wanted.

[01:46:15] I'm OK with that. But I don't promote things that I see as achieving anything. And I don't think just trying to find the sweet spot for transaction throughput on layer one is going to achieve anything. There is no sweet spot. It's a linear trade-off. You increase the cost. I

[01:46:43] John Carvalho: Think what it is. I think that some of us think about it as if we don't try to accommodate growth, that that could lead to death. And so if Bitcoin, say, nobody is using Bitcoin anymore.

[01:46:58] Eric Voskuil: What are they using?

[01:46:59] John Carvalho: Whatever alternative offered what they needed.

[01:47:02] Eric Voskuil: Are they using a coin with a bigger block size that's basically Bitcoin? A percent, potentially. That's what increasing the block size means. It means people moving to another coin. So for

[01:47:12] John Carvalho: The audience, I think I should disclaim that you have a little bit different way of describing what a fork is. In other words, would you consider that when we added Taproot that we forked and the old Bitcoin was dead? It's called a soft fork. We forked. I just want listeners to understand that you didn't spell that out. Most people don't know that that's what you mean. So people

[01:47:35] Eric Voskuil: Have been sold this lie that soft forks are backward compatible. They are not. If you go ahead and create a soft fork and run your own node, start rejecting blocks, you'll find out you're not on the chain anymore. They're not compatible. What makes them work for people that don't upgrade or don't accept the new coin or the new rule is that miners prevent them from seeing those blocks. They get censored. So every rule, every new rule that gets added is a new coin that can split off from the other coin, or it can start from the genesis if it wants.

[01:48:04] Fine. I don't care. But when you make a rule, you have created a new coin. And the question is only whether everybody who used the old coin is going with you or they're staying where they were. When Bitcoin Cash came along, some people went with them. Some people stayed where they were. When SegWit came along, same thing, right? When Ethereum decided to roll back, some people went with the original one and some people went with the new coin. They both still exist. This is how it works.

[01:48:34] This is a new money. It starts at zero value. And as people adopt it, if everybody goes, then it has value. So I know it sounds a little bit abstract and a little bit theoretical, but there's really no other rational way to explain it. If I just arbitrarily throw some new rule into the mix, it's not the same coin. Just because a bunch of people accept it doesn't change that fact. I can

[01:48:55] John Carvalho: Accept that. I just wanted to force you to explain it to the audience because it's not. All right. Yeah, I appreciate that.

[01:49:00] Eric Voskuil: I know where you're coming from.

[01:49:01] John Carvalho: Yeah, I accept it largely because of how Bitcoin Core doesn't patch old versions when they find vulnerabilities. They only patch the new version. And that's another signal of, hey, there's no autonomy that you have here if you follow Core because you just have Core. And then eventually, they find a CVE bug and they fix it in the new version.

[01:49:24] They don't fix it in your version, pre-taproot version. Well, I'll tell you the way the Bitcoin work.

[01:49:29] Eric Voskuil: We don't impose any forks. I have comments throughout the code of where I've gone back and researched as far back as I can go forks that Satoshi implemented without telling anybody, right, and trying to implement those as independent, configurable forks, even if it causes a break when you don't implement them or don't activate them. This has been the case for a long time. When you add a new, when Bitcoin forks, excuse me, when BTC forks in the Bitcoin, if it's activated and widely used, we'll turn on that fork by default.

[01:50:07] But you can turn it off. You can turn off all the forks. You can turn off BIP 16. You can turn off BIP 30. You can turn off any fork you want or turn them on. You can turn on a Litecoin fork and run Litecoin, right, test networks. So we don't impose those on you. We presume that most people are just follow the crowd. And so we activate by default the forks, or we enable by default the fork activations that are running. But we kind of give you base Bitcoin, right, or whatever chain you want to be on.

[01:50:38] I think we have configuration for, it's just configuration. It's not actually different. You don't have to recompile, but you can run mainnet, testnet, Litecoin, regtest, Litecoin, testnet, regtest, whatever, through configuration. And you decide what you want to run. And we're going to keep patching that and keep allowing you to run. So maybe the reason people want to run the old version is because they want to run the old rules, and they can't get the patch. Well, with our approach, you get the latest software, you get the patch, and you run whatever rules you want.

[01:51:10] We don't impose them on you. So I like to run sometimes just turn off all the soft forks and sync the whole chain, validate the whole thing, and make sure it all still validates so that nobody's been mining a soft working compatible block into the main chain. That's nice to see. Sounds nice, yeah.

[01:51:29] John Carvalho: I want to be able to run Bitcoin without taproot, and I can't.

[01:51:33] Eric Voskuil: Well, that's just a couple of forks, and turn them off.

[01:51:39] There's more than one reason for this.

[01:51:44] It's not just about giving people choice, right? Like to activate or not activate a fork. It's about maintaining the history. Where is the history, right? If it's all buried, it's hard to go back and figure out the subtleties of these different changes over time and what they meant, what they did. The code itself is bitcoind is just opaque. But we take that out, we give it a name, we give it a piece of code, and we give it a configuration parameter, and we say this was a change. It's got a name, and we do that for each one of these changes.

[01:52:18] And there have been a number of rule changes that Bitcoin Core has made that they haven't even documented, and not really. Not bipped, not discussed, just did it, and then there's been a couple that didn't quite go the way they expected, and they undid it, and then redid it. And so to me, it's a lot of extra work, but it's worth doing.

[01:52:43] BIP34 was supposed to provide height in coinbase, 43?  I can never keep it straight. But that was supposed to solve the BIP30 problem, which was duplicate transaction hashes resulting from duplicate coin bases on different heights. But it turns out that it introduced another problem, which was there was already older transactions with higher heights that weren't intended to be heights in those input scripts of those older transactions, which means that there is a problem down the road, which they then patched. And then unpatched, I don't know, there was tie-in with BIP90.

[01:53:29] So these things, they're not as straightforward as everybody seems to understand. And I try to pull them apart and describe exactly what people have been deploying over the years. BIP30 is another great example. There's three forks there. Not one.

[01:53:46] John Carvalho: I have one question left from my notes while you were talking so far. And sorry, Vlad, I don't know if you have questions that you wanted to get in. He's just

[01:53:55] Eric Voskuil: Making money on us talking. He's great. I'm enjoying this.

[01:54:01] Vlad Costea: No, but I do have some questions from the people in the chat. And there was Andrea, who basically set us up on Twitter, who has like a list of questions. So don't worry, I do have my part. It's just that I enjoy listening to you guys talk. And it feels like it's so casual. And I like it.

[01:54:23] John Carvalho: So I have to think about how to articulate the question, which is, so we talked a bit about the competitive aspect and the spectrum and how you could have a BTC-1234 and somewhere you would have the ones on the bottom. And the ones on the bottom would be distinguished from the ones near the top by what? Some sort of lower quality, lower security, lower cost, right? And my question is, when we look at the way the world works today, when you look at actual everyday commerce, the transactions that happen, the highest quantity, most of the transactions that happen, happen over some sort of trusted medium, whether that be through credit, credit cards, credit in your account and your bank.

[01:55:14] It's all credit. Yeah, it's mostly credit. And then when we look at what we've tried to do with Bitcoin in scaling, we notice that what people end up doing is trending towards credit again. We make Fedimints and we make Lightning and we make LSPs that power Lightning. And then Lightning is now moving towards this, you have the keys in the phone and the node on the cloud. So cloud nodes, it just keeps centralizing and you keep reincorporating trust. And so my question is, should we just stop with all ideas of Bitcoin as money in the sense of how replacing what credit currently does for us?

[01:55:55] In other words, only use the term in the way we discussed in the beginning as a designation, a categorization explaining what it is, but forgetting about how people use currency every day or what they actually use in credit for the most part. And just saying, maybe if we want to design a better solution for credit or what most people call money, maybe we should be talking about the best trusted solution and the most peer-to-peer oriented, self-sovereign oriented, whatever word you want to use, credit method if you want to extract credit from the legacy system.

[01:56:35] Eric Voskuil: So I wrote one of the topics in my book was about this idea of risk-free return. And I don't know if you remember, but there was a, again, anytime I have to remember names, it's awful. But there was a well-known Bitcoiner who passed away, I don't know, it was about a year after this discussion. I can't remember his name, unfortunately. But he had posted, it was like an academic paper, white paper on this idea, risk-free return. And I used it as the topic of my talk at the next Honeybadger.

[01:57:19] And so it goes to this question of credit.

[01:57:30] So I debunked the idea. We had a long discussion on Bitcoin Dev about it, me and him directly, and a couple other people chimed in. And then I gave a talk about it at Honeybadger. And eventually, I wrote a topic and eventually made it into my book and everything like that. But it was a really interesting academic exercise for me to kind of put my finger on what the problem was. I could sense the problem right away, but I couldn't really initially put my finger right on it.

[01:57:57] And again, he passed away like a year later. And I had only face-to-face met him and talked with him once. It was at scaling in Hong Kong prior to this. And it turns out, I talked to somebody, I think it was about a year ago, again, don't even remember who that was, but who had worked with him on it. And I found out from this conversation that he had basically, they had acknowledged what I had said was the case, and they gave up on the project, which I ended up feeling kind of bad about because he passed.

[01:58:27] I think it was his last big project that he worked on. So that also happened with, it wasn't about credit, but it also happened on the thing I mentioned earlier, Chia and Bram Cohen's thing. I critiqued it when it first was announced, big academic white paper raised like 20 million bucks or something right off the bat, make Bitcoin mining energy efficient. And my point was that it wasn't going to make it energy efficient. I pointed it out, and a couple years later, one of their PhDs contacted me privately and said, yeah, we're pivoting.

[01:59:03] We finally figured out that you were right. [unclear: They don't say these things] In public, but that's, you know. So I feel good. I didn't save them, in that case, as much time, but we can point out these things that don't make sense, get people to really think about them. One of the things that Bitcoin lacks is a, it tends to be an echo chamber, right? And even these things going back about economics and Mises and all this stuff, there's this accepted set of principles, fractional banking, inflation, risk-free return, credit, money, that there's just an echo chamber.

[01:59:40] So there's no real criticism of a lot of these ideas at the fundamental levels. And so I enjoy being able to add that value sometimes. And so that comes to this question of credit and money. Bitcoin is a money. And there have been attempts, like this one I mentioned, to build credit systems that have the characteristics similar to Bitcoin. In other words, Bitcoin being permissionless, having no counterparty, having it being self-sovereign, no trust in anybody else. And the idea of applying those principles to the credit economy is an important question, one a lot of energy gets put forward.

[02:00:29] And that also ties into this question of fractional reserve banking, which is a very poorly understood thing in the Bitcoin community. And again, I have to point out to people that I am absolutely a lifetime, ever since pretty much college, libertarian, anarchist type. Read all the stuff that they've read, have all the same motivations, the cypherpunk for a long time. But I don't delude myself in about how these things work. And so the problem, so one thing that people don't understand that relates to this is that the distinction between credit and money is that credit has to be settled, generally settled in money.

[02:01:16] Money doesn't have to be settled. It is what it is, and that's it. There's nothing that it depends on. Lightning is technically credit. They are Bitcoin transactions, but they're not money until they're settled. You can trade them. They're credit. You can trade credit, but they're not money until they settle on chain. So you have received the thing that is not something that represents something else. So what's interesting about it is that it is a sort of non-custodial, sort of, credit.

[02:01:53] Economically, it's a money certificate, like the dollar being representing gold. A Lightning transaction represents an on-chain transaction on a kind of one-to-one basis, and it's non-custodial to a certain degree. So in that sense, it's achieved. This thing I'm describing is this idea of doing credit and getting the benefits of credit without the things that seem to be necessary for credit, which is counterparties, custodians, et cetera. But as has been known from the start and as we found out, Lightning is not entirely that.

[02:02:33] You have to have a certain amount of trust or distrust in your counterparty because you have to monitor them. Then you have to be able to settle before a certain amount of time, or you're going to get robbed. You can't exist all in credit all the time, which is one of the stories that was being proposed for a while. And there's a cost to it, like credit. There's locking up your money in channels and even a complexity cost. So there are all these aspects of credit. It takes time to settle.

[02:03:02] It has to be settled. And there's time and risk involved and settlement costs, all aspects of credit. So Lightning is a money certificate that is sort of non-custodial. It's credit. People hate to hear that. I don't know why. It's just academic to me. But the point there is that credit always exhibits these characteristics. Settlement time, settlement risk, cost, settlement time risk and cost, counterparty risk, right? So the idea of this paper on risk-

[02:03:41] John Carvalho:  Just a quick question. Would you classify mempool transactions as credit?

[02:03:47] Eric Voskuil:  Well, it depends on if somebody's giving you something for them. When you say mempool, you mean unconfirmed, right?

[02:03:52] John Carvalho:  Right, right, because that's what Lightning transactions are. They're just unconfirmed Bitcoin transactions.

[02:03:56] Eric Voskuil:  Well, but they're anchored in a certain way so the attempt is to provide them a security model that unconfirmed transactions don't have. So Lightning achieves a level of security on unconfirmed transactions that does not exist otherwise. The question is, is it the same as Bitcoin? Absolutely not. And I don't think any honest person would tell you that the security model in Lightning is the same as in Bitcoin, or the cost, right? It can be cheaper because of lower transaction fees. It can be more expensive because you can get robbed if you're not paying attention, those kind of things.

[02:04:31] So it's different. I think everybody, being honest, would acknowledge that it's different. When it comes to unconfirmed transactions, if I walk into a store and I give somebody a transaction and they give me the goods, I walk out with a chainsaw, they've given me credit. They've extended the chainsaw with no payment. There's a promise to pay. And only I can undo that promise if it's my keys. So I could double spend that transaction before they can get it confirmed and I could steal the chainsaw. They have extended credit, risk, settlement time, settlement cost, right?

[02:05:10] And it's like in the old days, accepting a paper check. Somebody walks in, right? That's the same thing as an unconfirmed transaction. Probably not.

[02:05:19] John Carvalho: I mentioned it because I think that might help people accept defining Lightning as just a unconfirmed transaction. So if you accept them, it's a payment, it's a credit.

[02:05:35] Eric Voskuil: Yeah. I mean, even taking a single confirmation is credit, and we attack against you, or a 51% attack if you go further up right there. The point of settlement in Bitcoin is not clear, right? But there is settlement, right? Settlement means the transaction is over. I've paid, and you've received. And if somebody comes along and rolls back that transaction, and I wasn't even involved, it's not my problem, right? Just like if somebody robs your-

[02:06:08] John Carvalho: Sorry to add another nuance, but why can't I say that settlement is determined by the person accepting the Bitcoin instead of by the chain? In other words, if I give you the chainsaw, I feel I have settled the trade. You know what I mean? I accepted your credit, and you accepted my chainsaw.

[02:06:27] Eric Voskuil: Well, you could. So every trade is a contract, right? And a lot of times, these contracts are just implicit. I walk into a restaurant, I sit down, I eat, I pay. There's a contract there. We just didn't sign it, right? And that would be upheld by court. If I didn't pay, I would be guilty of stealing the food, because there's an agreement that is implicit because it's so common in society, right? When I walk into the 7-Eleven, and I put something on the counter, I pay, and I take the goods, but there's an agreement that I'm not taking the goods unless I pay, right?

[02:07:00] And I gave him extra money, and there's an agreement that I'm getting change back. We don't have to discuss it. But if I don't, he robbed me. And that's because he violated that contract that we have that we're trading at this price. So the same thing holds with Bitcoin. If I walked in to a place, and I bought a chainsaw, and I gave the transaction, and I walked out with a chainsaw, and we had explicitly said that whether or not this transaction confirms on the chain, it's settled. Contract can settle in any terms you want, right?

[02:07:31] So you could say that. Or you could say, if it reaches six confirmations, then it's considered settled. Otherwise, you owe me the chainsaw back. You could do that, right? So the free market deals with these questions. And you could say that if I gave you $100 bill for the chainsaw, and it turns out to be counterfeit, you owe me the chainsaw back. That's kind of generally the case, right? Again, these are kind of socially implied because they're so common. We don't want to all have to sign contracts every time.

[02:07:58] As the value of the price of these things goes up, we do sign contracts. We're trading houses and cars. Now we actually start delineating what the criteria are. So you could do that with unconfirmed transactions. You could say, you know, you give me the unconfirmed transaction, I'll take the risk. Because it's only a cup of coffee. The cost is low. And if you start doing it more, I'm going to start... I won't take you in my store. The same thing used to happen with checks, right?

[02:08:20] You go behind cash registers, there'd be a list of bad checks with people's pictures next to them sometimes, so you don't accept checks from this guy. Because last time we did, he double spent it. So there's nothing new about any of this. Things aren't like credit cards. Charges aren't settled for like six months, right? I could reverse the charges. The guy could get stuck with the stuff. We could have a contract that says, if I reverse the charges, then I owe the stuff back, right? These things start turning into statute and law because they're so common.

[02:08:53] So nothing is ever as clear as it seems, because we tend to generally operate in the layer where we're not explicitly doing these things, at least consumers do, right? But lightning operates under certain assumptions that the other person is not going to rob you, but they can. And if you don't catch them in time, you're robbed. Does that mean it was settled properly by agreement? I don't know. What was the agreement, right?

[02:09:20] John Carvalho: You could still take them to court, et cetera, if you wanted.

[02:09:23] Eric Voskuil: Right, you could. But what if they pulled out a piece of paper that said it was settled regardless of whether it was reversed in the future? OK. You could do that. I don't know why you would. But yeah, what would happen typically is there would be some convention, like unless it was explicitly stated, the assumption is you won't double spend this or close out the channel and prevent them from getting their money back. I don't want to get into details. But those are all aspects of credit.

[02:09:53] Every trade is a contract which is then settled. It's just that a lot of times we don't bother to verbalize or write the contract out. I

[02:10:06] John Carvalho: Think my question pulled you, my added questions pulled you away from the original question, which is trying to comment on like, basically, if there's a way to solve or design better, you know, what is typically used in commerce, you know, credit. And in other words, right now, we have Bitcoin is trying to say lightning network would be our answer to replace credit cards. You've even heard lightning network is the visa. Debit cards, maybe this kind of whatever it may be. Yeah, sure. Debit cards. Well, even the credit cards, debit cards and credit cards are both credit and practice, right?

[02:10:41] Right.

[02:10:42] Eric Voskuil: Debit card is just a it's more assured by the balance, right? So you have to put money in the in the channel, which you have to have in order to make actually I

[02:10:55] John Carvalho: Can think about how to reframe the question better. For as far as if we're designing for censorship resistance of everyday purchases, in other words, so that in other words, where I think we agree that maybe Bitcoin is not the best thing for that. And so if we were designing the best thing for that, we would notice that trust seems to be a huge part of being able to have a successful design for that. Now, can we minimize the amount of censorship resistance by designing something that is more likely to be successful?

[02:11:27] Like a mutual credit system or some sort of peer to peer credit system?

[02:11:34] Eric Voskuil: Yeah, yeah. And I think, you know, they'll continue to be ongoing efforts to do these things. But that's what lightning is, right? It's an effort to get the advantage of kind of credit based systems while minimizing or maximizing the censorship resistance. But what's happened, you know, and this was, again, predicted from fairly early on is that is that, you know, in order to be efficient, lightning has become largely centralized, and it'll continue to work like that until it doesn't, right? There's no there's no no real assurance there.

[02:12:10] John Carvalho: My issue is, I don't like when Bitcoiners try to design something that's dead. In other words, when it's a problem that actually many people face in many situations, but they only try to solve it on lightning, or they only try to solve it on Bitcoin. Like, for example, I don't know how you say you probably don't follow lightning. But we have we had BOLT 11, which was the first payment protocol invoice format. And then they made BOLT 12. And these are incompatible payment protocols. So now you have two. And BOLT 12 supports some extra metadata for being able to do things like offers or reusable invoices, or subscriptions.

[02:12:46] And these are all just like meta use cases, right? These have nothing to do with lightning itself. They have to do with money and commerce and trade and these kinds of things. And so I'm wondering if the reason I'm getting to all this is partially for my own bias, because I mentioned to you in the past that I want to describe some ideas, but also because the one guy who had a bunch of questions for us, I think his ultimate hope was that we would discuss actual solutions for the things that nobody's actually solving.

[02:13:15] In other words, how do we actually scale Bitcoin? What do we do about scaling Bitcoin? And if we can't do what we thought we could do, what could we do instead? And so I do see an opportunity for designing something that is payment method, designing a payment system that is settlement method agnostic. And so we use credit. In other words, could everyday transactions be made out of a peer to peer credit system that was locked, that was integrated with a variable settlement system where basically you would say, I want settlement now.

[02:13:51] Eric Voskuil: The problem with the term peer to peer credit system is that they don't exist. So they credit.

[02:14:00] John Carvalho: You mean they can't exist or that nobody has made them?

[02:14:02] Eric Voskuil: Well, credit is lending somebody your money or your property with a promise to get it back. Now, peer to peer has different meanings to different people. In the context we're using it here, I think you meant trustless, right? Not just a distributed network. No, I

[02:14:33] John Carvalho: Don't think credit is trustless. Okay,

[02:14:36] Eric Voskuil: Well then PayPal is a good example. If PayPal takes Bitcoin, it's Bitcoin over a peer to peer, or it's Bitcoin over a network. So

[02:14:42] John Carvalho: PayPal is provided by a centralized provider. I'm suggesting something that is provided by the individual.

[02:14:49] Eric Voskuil: But if it's not trustless, it's...

[02:14:53] John Carvalho: It's relative trust. So in other words, you have a social... May I describe the idea?

[02:15:03] If you're okay with it, I know it's not exactly a Bitcoin topic. So the idea is basically that imagine each individual had a ledger, right? And I say, okay, I will extend $10 of credit to Eric, one Bitcoin of credit to Eric, and 10 bananas of credit to Eric. And maybe you've extended some credit to Vlad. And instead of using the Lightning Network or Bitcoin or anything at all, we just have these signed ledgers that we can share with each other. And that we can then form basically routing of credit using our social graphs over which credit limits were mutual.

[02:15:48] And so we have this kind of mutual credit routing system, somewhat like maybe Hawala plus actual credit. And so the low level of all payments that would be done within our economy of people that use this system could be done in credit most of the time. But then eventually we would hit moments where we would want ultimate settlement, and we'd have to request for settlement from specific individuals. But we would separate these capabilities. We would say, you have a list of a ledger of signed with your key of what people owe you.

[02:16:23] You have proofs of what people owe you and proofs of what you owe other people. And people can provide these proofs to each other in order to establish a social graph of channels.

[02:16:37] Eric Voskuil: Let's consider that we already have a certain aspect of this. Bitcoin is a ledger. Everybody has their own coin on that ledger, and they spend it to somebody else that transfers. No, I'm not

[02:16:46] John Carvalho: Talking about a master ledger. I'm talking about relative ledgers.

[02:16:49] Eric Voskuil: Well, it doesn't matter.

[02:16:51] You're talking about P2P, so it has to be done somehow. So my ledger is all my unspent outputs or inputs that I've received. That's my ins and outs. That's my ledger. It's a P2P system, so it's stored in the cloud in everybody's Bitcoin node. You can take that as an example of this type of system. The exception is when you're talking about credit, not just transferring the money. Credit is I give you the money. I actually spend it. I'm extending your credit, so I send you the money.

[02:17:21] This is what we got into in this discussion on risk-free return. There's no guarantee of that money coming back. There's no cryptographic way to guarantee that money's coming back. That's the whole point of credit, and this is the lengthy discussion we had on this risk-free return topic. So what, again, the gentleman that had done this wanted was a covenant, and he wanted a covenant to guarantee that return. So if we could get a covenant in Bitcoin that said, after a certain amount of x, that money automatically came back, now we can do what you're describing, peer-to-peer lending in a trustless manner.

[02:18:01] Everybody's issuing each other credit. Why do

[02:18:03] John Carvalho: We insist that, why does it have to be trustless? Why can't it just be on reputation?

[02:18:08] Eric Voskuil: Because it's risk-free. That was the whole point, risk-free rate of return. So I have this capital, and I want to put it to you. So I want to earn on my capital, and somebody else wants to borrow it in order to produce, which is necessary. There's no production without lending, without investment, same thing. So I lend this capital to production, and I want to make sure I get it back because I want a risk-free rate of return. And when you look at that formulation, this doesn't cover your whole scenario, but I'm explaining a very clear-cut example on Bitcoin of what you're describing with the limitation that it's supposed to be trustless, which is what people seem to want to do.

[02:18:48] They don't want to introduce a big central bank into the whole system.

[02:18:50] John Carvalho: It's not what I want to do. I'm not implying that at all.

[02:18:54] Eric Voskuil: But what happens is, and this, again, I think became the final resolution of this question, was if you guarantee the money's coming back under some time constraint, block height constraint or whatever, then the imputed value of the loan at the time you make it is zero.

[02:19:16] John Carvalho: I agree. I mean, I could see that, obviously, as well.

[02:19:18] Eric Voskuil: Because as the money propagates to all the people you're spending on, eventually, you can't actually lend it out.

[02:19:22] John Carvalho: They can't use it if it has to come back.

[02:19:27] Eric Voskuil: Why was this not obvious to the academics who wrote this paper? This is what I mean about Bitcoiners. This paper was on Bitcoin Dev. You can go look it up. People were critiquing the nitnoid details of this thing, and I went up and I said, wait a minute. There's something really, really wrong with this. They did

[02:19:45] John Carvalho: This with Lightning, too, how you were going to be able to just passively put your Bitcoin in a Lightning node and make money off it. And I was like, who's Bitcoin? You know what I mean? I only have so much Bitcoin. Then what? Where does the Bitcoin come from? They wanted to make it look- like banks could just loan out their Bitcoin and put it on Lightning, and it would be some sort of risk-free

[02:20:07] Eric Voskuil: Return fallacy is a big deal in the context of this discussion because it does drive a lot of the mentality. It's also very closely tied into the full reserve fallacy. The idea of lending your money while keeping it all in reserve at the same time, earning on it while taking no risk on it. All these fallacies are connected, and they just break off into different aspects, which I write a topic about. But this risk-free return fallacy, you understood it. I don't know if the viewers will all get it. I'll explain it a little bit more slowly. I lend you money, which means I spend it to you under covenant. You then use it to make something so you can sell it and give me my return.

[02:20:54] You hire some people, you spend the Bitcoin to them. They go out and pay their rent. They spend the Bitcoin to their landlord. Their landlord goes and pays their taxes, and they spend the Bitcoin to their tax authority. And then they go out and issue it as food stamps to somebody, and they get their food. And then the store is holding this Bitcoin in the end, who had no connection to this loan whatsoever. And then all of a sudden, on zero day, that Bitcoin disappears and comes back to me.

[02:21:23] So as soon as somebody knows that there's a covenant associated with this Bitcoin that's being spent, they won't accept it, because they know that the next person won't accept it, because they know the next person won't accept it, because they know it's going to zero tomorrow. So that's called the net present imputed value. Like the present value is x, but I can impute that in the future, it's going to be worth zero, which means, sorry, I can predict that the future is going to be worth zero, which imputes a present value.

[02:21:52] It's a present value of zero. And that is essentially why these schemes don't work. You do not get risk-free return, right? There is. So I think that's, I mean, I'm kind of emphasizing it. We've already covered it, but I think it bears repeating that there is no full reserve lending. And this is, so I should mention this, because alluded to it a couple times. Rothbard talks about full reserve and fractional reserve in Man, Economy, and the State, which I said is a very good book, and he does not make this error.

[02:22:28] He's very careful. When he says banking, he's talking about full reserve banking. When he says banking, again, this is relevant to this large discussion, because we're talking about lending, right? When he says banking, he's explicitly not talking about lending. He actually calls it a money warehouse. In order so that people will not make the mistake of assuming he's referring to lending when he's talking about banking. He says, if you put your money in a money warehouse and you get a certificate that says it's your money and some guy's holding it, he's a custodian.

[02:23:06] He's making an analogy to the dollar and the gold custodian of the Federal Reserve, right, pre-decoupling. And he's making this analogy because he's trying to explain Mises, but he's trying to avoid making the errors that people impute to Mises, right? He says, in a case where there's no lender there, they're not lending your money, right, and they're not paying you a return, you're paying them to hold it, right? They're securing it for you. You're not getting a return because there's no lending to earn the return.

[02:23:37] There's a cost of holding, which is your, I forget the term. Anyway, so in that case, right, if the custodian takes that gold and then uses it, sells it, lends it, does anything with it, except for holding on to it, right? They're holding only a fraction of your money in reserve. That's what he means by fractional reserve, right? Or what's more likely is your token, your money certificate for that gold. The gold certificate is circulating like the dollar was. And the custodian who has the sole authority to print those certificates, right, this is under monopoly control, any counterfeit laws, he issues more.

[02:24:22] So now he does, he only has a fraction, a sub 100% fraction of the reserve for the certificates. This idea of fractional reserve only applies to money certificates, not to lending, right? And he's explicit about that. And I quote him in my book because I'm like, why can't you people understand that when he says this, this is what he means. He's very explicit about it. He says this is not applied to lending. If you're lending, you are always lending under fractional reserve. There was no such thing as lending.

[02:24:54] You are always lending something that you hold in reserve. You have to give it up. And not only do you have to give it up, as we talked about in the covenant scenario, right? The first free return scenario, you have to give it up with no possibility of getting it back except a promise, right? That's it. So you can take a lien on, you can lend somebody some money to fix the roof on their house. You take a lien on their house, right? And if they don't pay you back, you sell their house and you get it back.

[02:25:22] You take it under, I forget the term, collateral, right? You collateralized the loan. But there's no guarantee the collateral is going to exist either, right? You can take and hold their collateral, but now they've lent to you. So the scenario has actually been reversed. They lent you their collateral. They may or may not get it back, right? And you're giving them a smaller loan. So the same problem still exists. So all lending is always fractionally reserved. I lend a portion of what I own and I keep the other portion.

[02:25:54] And that's my fraction. And sure.

[02:25:57] John Carvalho: So the design I propose is that there's no reserve, the reserve is just a separate system. In other words, whether whether we wanted to require somebody prove that they have some sort of assets in order to receive credit would be separate.

[02:26:12] Eric Voskuil: But the amount I so if I if I have 100 bucks, and I lend out 10 bucks, I bet 90 in reserve. How does the 90 matter at all? Doesn't matter. Right? I got 10 bucks, it may or may not come back. So what I got 90 to live off of.

[02:26:24] John Carvalho: Right? That's fine. I guess I'm just trying to I'm trying to bring it back to that the idea is not about trustless and the idea is not about having reserves. It's about using trust. If

[02:26:36] Eric Voskuil: You have to, but people should, you know, what I'm trying to get as you need to, people need to exclude entirely this concept of no trust, right? The only scenario where this is possible is when you your money goes out the door, and it may or may not come back. There's no guarantee no cryptographic guarantee we can make that will come back because if there is that money that went out the door isn't worth anything. So so we have a standard lending scenario. How do we enforce how do we do this in a trust and it's like an anonymous p2p way?

[02:27:12] I just so so some guy might have reputation, right? Some person on the other end of the you know, we got a we got a system and it somehow builds up reputation and this guy always pays. So I keep investing in him and he keeps paying. Great. And then he doesn't pay and he loses reputation. He doesn't get paid anymore. There are systems like this, right? There are there are p2p lending systems that work like this. I mean, they're run by generally run by a central organization, but they pair people who want to lend with people who want to borrow and they build up reputation and whatever, right?

[02:27:40] I don't I don't know what they're called, but they do exist. So you could take one of those and make it in a peer to peer way. That's great. But what is it? No economy is going to exist without lending. There is no production without lending. You can have a money like Bitcoin that nobody lends, but the all the production will occur using other forms of trade, other monies, right? Other forms of investment that won't, you know, if the entire world operated on Bitcoin and nobody lent it, we'd all just die.

[02:28:13] There will be no production. So the mom, what I'm pointing out is it's it's important if we imagine like some kind of global black market economy working on Bitcoin, there has to be lending. And I'm also pointing out that lending has to have to incorporate risk, and risk has to incorporate some mechanism of dealing with failure to pay, right? And lightning getting pretty close to kind of this risk free return type lending basically has no return, right? Well, as soon as you go to fully risk free, there's no return, as we pointed out in the risk free return discussion, right?

[02:28:57] So there has to, you know, if you're going to have production, you have to have lending. Lending has to involve risk and risk has to involve conflict resolution, you know, in some manner. That generally that generally means people getting face to face with guns and, you know, dealing with dealing with direct conflict. So I don't personally work on those systems. They have to exist. They will exist. They can't stop them from existing. And they're really not essential to the value proposition of Bitcoin, which is that the underlying money, right, is not under somebody's control.

[02:29:36] That's, to me, the important thing. You're on mute. You're

[02:29:42] John Carvalho: Sorry, I mean, to imply that this idea would compete with Bitcoin per se, so much as if we were to solve a peer to peer credit system, then it would be a good thing to point at as why we don't need to make channel factories where there's three people in a lightning channel, because we have already solved credit in a purer way outside of Bitcoin.

[02:30:09] Eric Voskuil: Right, but the whole idea of lightning and channel factories and all that stuff is that you're doing it in a trustless manner, but the response to that is it's going to be it's not trustless, right? So I think you've got you really got two things. One is money, which lightning is trying to be, right? It's trying to solve the cost. It's trying to reduce the cost of the transacting and the speed of the transacting, right, of the money, not credit, even though it is credit. It's a money certificate, which is a, you know, kind of the light, the thinnest form of credit.

[02:30:38] You have, which is like a dollar represents a certain amount of gold. That's a money certificate. That's what lightning technically is. And that's why it's fairly close to being the money while it still doesn't have the same security models of money, just like a gold certificate, right? So as soon as you kind of get away from a money certificate and the ratio is no longer, you know, sort of guaranteed by the system or sort of guaranteed by the system. Now you're dealing with just credit, and it's not going to be trustless.

[02:31:10] It could be P2P, but it's not going to be trustless, right? You can develop a distributed website where people... The whole point

[02:31:15] John Carvalho: Is to establish trust and to digitize trust.

[02:31:21] Eric Voskuil: Right. I mean, you could like Silk Road, right, had a centralized website, which had kind of anonymized, aside from the owner, right, anonymized P2P interaction with reputation and let, you know, I send you some money and you send me some goods. That's a loan, right? There's credit involved there. It might not show up. And the fact that I keep, you know, people keep paying is the fact that they deliver. That's based on reputation. But that's credit extension over Bitcoin, over a system that's anonymized, but still subject to centralized control.

[02:31:54] You could take a system like that and decentralize it. And then you have what Amir developed, which was DarkMarket, which became OpenBazaar. That presumably was the objective of OpenBazaar and DarkMarket was to create a decentralized P2P, anonymized market with reputation where people could lend each other, you know, they could spend or lend money and then later get the goods or the money back.

[02:32:19] John Carvalho: I did follow that project while it was alive. I'm not sure what ultimately killed it or why it didn't gain as much attention. OpenBazaar is

[02:32:25] Eric Voskuil: Actually back up, maybe back doing stuff. Really? Yeah, might be worth it. I think I saw something like that.

[02:32:32] John Carvalho: I recall there was something, there was some issue they had with their way of shipping. It was always one indexer. And so they ultimately had to have sensorability because they didn't have variability in the indexing, if I remember correctly.

[02:32:46] Eric Voskuil: Yeah, sorry, I don't know the details. So they used, they used, Amir built it on the Bitcoin and they used libbitcoin for some time initially. And that's why I knew more about it. And I think I still follow the guys and I thought I saw something about it coming, you know, being resurrected. So we're

[02:33:04] John Carvalho: Building similar things. Like we have, we have this key based identity system that where we put the DNS, right, we signed DNS records with a key and we put those in mainline DHT, the torrent DHT. And this gives you a way to have like a self-sovereign way of routing and discovery. And so we're with a payment matching protocol. So the, any website that's hosting the data itself in this system would be only waiting for a proof to release data. And so the actual payment in the settlement is happening out of band.

[02:33:42] So you can kind of have a peer-to-peer e-commerce as well, and just relying on a centralized provider to release the data. Really, this is mostly for digital e-commerce, but you could, you know, you could make this work for regular physical e-commerce as well. Yeah, so these are areas I'm very interested in. And I did always followed OpenBazaar and this kind of

[02:34:02] Eric Voskuil: Thing. Yeah, so those are, I mean, those are, you know, obviously there's a market for that kind of thing. I mean, I found Bitcoin because of Silk Road, because I think it was the Forbes magazine article that Andy Greenberg wrote. And it was obviously very popular and still, you know, that stuff continues to be very popular. So those are, those are use cases that, you know, do they require lightning? I don't know. I mean, I've never had any problem paying somebody with Bitcoin with a fairly nominal fee.

[02:34:36] You know, I pay people that translate my book, you know, pay for conferences, whatever, you know, just I don't use it a ton, but I never had any problem using it. And so I kind of question whether, you know, is the, what's the scenario that we're envisioning when we're talking about lightning? You know, I know there's this high volume scenario where everybody, you know, everybody needs a Bitcoin and a UTXO. But where are these people? All I can see is people speculating. I don't care about them.

[02:35:14] So I, it seems to me like, you know, when Bitcoin starts getting a bit expensive for people, they, you know, they start using Litecoin or something else. And I don't even think there's been enough demand to overwhelm Litecoin in those scenarios. So if there was, Litecoin would become expensive, and there'd be something else presumably, right? And I'd like to see, at some point, a wallet that just, you know, atomically transfers between different levels of security in a case where people don't even know the difference. You know, I want some more secure, I want to, you know, put my life savings over here and, you know, have this X level of security after a certain amount of confirmations.

[02:36:00] And I want to, you know, take a piece of that out and have a little bit lower and I want to have some over here I buy my coffee with and maybe some... For what it's worth,

[02:36:08] John Carvalho: Our wallet doesn't do automatic switching, but we have a wallet called Bitkit, a mobile app. And we at least have a mobile app, a mobile wallet called Bitkit. And it supports on-chain Bitcoin and Lightning. And there's a Lightning node in the wallet. And the way we portray this to the user is that on-chain Bitcoin is called savings, and off-chain Bitcoin is called spending. And so when the user wants to move from savings to spending, they have to configure a Lightning channel, essentially.

[02:36:37] Eric Voskuil: So what's the kind of, to the end user, what's the difference between doing that, which requires them to make some amount of their money, you know, unusable in this channel, or usable in a limited way, right, in this channel, unless they put it in a centralized Lightning authority, and then they can use it more generally, right? Versus, say, doing an atomic swap into Litecoin from Bitcoin, paying that fee periodically, those two fees, right? And then being able to use it at, you know, that chunk of the subset of the money for whatever they want, presuming people accept Litecoin, for example.

[02:37:14] John Carvalho: Several nuances that, well, even in atomic swapping, you have exchange considerations like slippage, agreeing on a price, you know, liquidity in general. As far as I know, there's not a lot of, there's not like libraries you can just plug into your wallet that will set up atomic swaps.

[02:37:32] Eric Voskuil: Well, like I said, nobody's ever worked on it. Nobody works on this.

[02:37:36] John Carvalho: I always wonder, like, people make atomic swapping sound like magic, but why aren't we atomic swapping everything all the time? I don't understand. But yeah, I'm guessing there's more to it than that. In other words, I don't think it's just that people aren't working on it. I think there's a challenge there. There's a price

[02:37:53] Eric Voskuil: Agreement, but otherwise, I don't think there's, you know, the price agreement and a fee, right? Price agreement doesn't have to be centralized, but people have to have some idea of how they value the money and how they value the fee. And so, but that's the case no matter what,

[02:38:07] John Carvalho: If I'm buying something... But another nuanced issue you have as well is that like, nobody accepts Litecoin. And so... Again,

[02:38:13] Eric Voskuil: Nobody accepted Lightning before they started it. And so, and people, you know, they're... Right,

[02:38:18] John Carvalho: But it's not enough for it to be there when there's congestion, because it needs to already have uses.

[02:38:24] Eric Voskuil: No, no, not my point.

[02:38:25] I'm just saying from a technical standpoint, what's the difference here, right? Like, this already happens. People already, you know, and maybe it's largely speculation, people moving from chain to chain, you know, like, but...

[02:38:39] John Carvalho: Yeah, I think it's like when people want to move Bitcoin from one exchange to another, they'll send it as Litecoin because it's cheaper. But that's only because the exchange accepts Litecoin, but merchants don't.

[02:38:50] Eric Voskuil: How many people, almost no businesses accept Bitcoin either, right? There's almost nothing. The only times I can spend Bitcoin, I said I do it, you know, periodically when it's useful, but when I'm interacting with another Bitcoiner, that's pretty much it. I know there's more, but it's, you know, I don't, nothing I do on a daily basis do I encounter this thing. You know, I could get one of these things that transfers my Bitcoin to dollars and then does it for me, and that's kind of pointless. So, yeah, Bitrefill, I guess, maybe, does that, is that what we're talking about?

[02:39:23] But like, to me, that's not, that could, if it's centralized in that kind of way, then yeah, they could just take Lightning too, right? Then now I've got access to everything. I'm not sorry, Lightning, Litecoin, right? So I look at this like, well, what's this big distinction that's being made, right? It goes back to the maxi question. Can I keep it all on the one chain and therefore drive my stack higher by making all the demand on one chain? Yeah, if you can keep that, but what's going to happen is, as it gets more costly, it's going to move somewhere else.

[02:39:58] It could move to lightning and therefore reduce fees and reduce demand.

[02:40:05] But I think a big part of the demand for layering comes back to this idea that everything must be one coin. And that's why you get proportionally excessive complexity trying to keep it on one chain without anybody even looking at the possibility of doing it otherwise. Is

[02:40:28] John Carvalho: It fair to say, then, that your stance is just quite simply, Bitcoin does not scale, we should make no attempts to scale it, and the actual phenomenon that happens when Bitcoin needs to scale is competition emerges? Well,

[02:40:42] Eric Voskuil: There's BTC, there's BCH, there's all this other shitcoinery, there's LTC, and there's Bitcoin. And I know people have a hard time with this, but nothing in Satoshi's paper describes BTC. It describes Bitcoin, which is a set of concepts that are much broader than BTC. We're not talking about the details of script or anything. I

[02:41:05] John Carvalho: Understand your desire to abstract the design, but that wasn't my question.

[02:41:09] Eric Voskuil: Well, I'm just describing what is. The paper defines the term Bitcoin. It came out and said, this is a concept called Bitcoin. That concept applies to Bitcoin before SegWit and after SegWit, BCH, BTC. These are different rules. How does it still apply? Because everybody accepted the change. So that's why we developed trading symbols to disambiguate. We have BCH, we have BTC, we have LTC. What are they doing? They're disambiguating all these different implementations of Bitcoin. And if you take a fork, if a bunch of, say, people wanted to use their activated soft fork their way off of BTC, and they did, they would say they've got no BTC.

[02:42:01] And the people that didn't fork off would say they've got BTC. And there would evolve another trading symbol to disambiguate the two. And this will continue. But these things are those would both be Bitcoin. That's my point.

[02:42:17] John Carvalho: Right. But when I discuss trying to scale Bitcoin, and when anybody discusses it, they're never trying to discuss scaling the idea or the design. Well,

[02:42:25] Eric Voskuil: That's where I would differ. Bitcoin, to me, is not about any one historical chain, right? Maxis want that. But you have

[02:42:33] John Carvalho: A logical consistency in that you already conceded that describing these other chains as competition is accurate, right? And so you can't, competition and scaling are not the same concept.

[02:42:46] No, that's not true.

[02:42:47] Eric Voskuil: They're all truly, clearly independent chains. And they're all obviously competing with each other. That's an economic principle. You can't deny.

[02:42:55] John Carvalho: Right, right. But how do you call them, how do you call them competition at the same time as calling them scale?

[02:43:01] Eric Voskuil: I'm not saying anything. I haven't used the word scale once in this conversation. What I've said is they are all Bitcoin. If they conform to the principles in the paper, they are an implementation of Bitcoin.

[02:43:14] John Carvalho: Satoshi implemented one. According to Satoshi. And he changed it.

[02:43:17] Eric Voskuil: He changed the rules again. He changed the rules again. Didn't tell anybody. They keep changing. There's new rules all the time. Right? There can be the case, and there has been the case where one splits off and keeps going and the other one keeps going.

[02:43:30] If they're conforming to that paper, they've done the same thing he did, there's still Bitcoin, right? So Bitcoin is a concept. It has certain value to people. And that's what I care about. I don't give a shit about which chain it is. I want people to get the value proposition.

[02:43:48] John Carvalho: I don't think that's true either. I think you do give a shit because you only work on one implementation. I don't

[02:43:55] Eric Voskuil: Work on so many things. I don't work on, as Vlad will tell you, you look at my old thing. But why do

[02:44:00] John Carvalho: You choose the one you chose? Why didn't you choose BCH?

[02:44:03] Eric Voskuil: Because I started like 11 years ago. It didn't exist.

[02:44:07] John Carvalho: I can't be the only reason.

[02:44:08] Eric Voskuil: I just, to me, it's got the, I started with it because it was first. Amir started the project. I started the project to make a wallet. I kept working on libbitcoin and I just kept working on it. That's it, right? It's what I know.

[02:44:21] John Carvalho: Well, he became more altcoin tolerant in practice.

[02:44:24] Eric Voskuil: When the Litecoin guys came along and they wanted me to support Litecoin, I supported them in adding code to our code base so that we could, using configuration changes only, employ Litecoin.

[02:44:36] And that, as far as I know, still works. [unclear: It cost me very little effort.]

[02:44:39] John Carvalho: None of what I'm saying is questioning your integrity. What I'm trying to do is isolate a question for my own uses, which is, or for when I talk to other people, which is just simply, I stated earlier that, and you agreed with again just now, that different blockchains or different monies compete. But my question was, and what I asked you was, so was it fair to say that your assessment is that Bitcoin as a concept or, no, sorry, the Bitcoin, any individual Bitcoin chain does not scale, right?

[02:45:15] Eric Voskuil: Would you agree with that?

[02:45:16] That's a topic in my book. Bitcoin does not scale.

[02:45:19] John Carvalho: Okay, okay. I'm establishing the basis here for the audience and for myself. So if Bitcoin does not scale, when people discuss scaling Bitcoin, what your response is, there are many Bitcoins, and this is what happens when Bitcoins needs to scale.

[02:45:33] Eric Voskuil: So the concept of Bitcoin scales through, scales what we call horizontally, right? If it gets, if one chain gets too expensive, another one will come up. It will happen. It has happened. It happens automatically, right? The

[02:45:47] John Carvalho: Definition of scaling, as I understand it, is rooted in applying additional resources to a specific network to increase throughput, and these are separate networks.

[02:45:57] Eric Voskuil: Well, scaling is, this concept of scaling in computer science has nothing to do with networks. The concept of scaling in computer science means, specifically, or in engineering, I shouldn't say computer science, in engineering, scaling is adding more hardware gets you more throughput of whatever thing you're trying to add hardware to increase. So if I increase, so for example, and it's proportional, so if I proportionally, if I increase my bandwidth, I can transfer twice as much data, okay? I added the hardware to

[02:46:26] John Carvalho: Be able to go twice as much.

[02:46:27] How do you establish the context, though? Because I could say that everything's just scaling all the time. When I buy a new computer, I just scaled somebody's beef in Africa.

[02:46:38] Eric Voskuil: When you're working in engineering problem, right, and you're trying to figure out how to get more water through the pipe, you figure out, I've got to double the size of the pipe or increase the capacity of the pump. I change the hardware. Now, what if I double the capacity of the pump and I get no increase in throughput through the pipe? It doesn't scale. Something is preventing it from scaling, right? Maybe I have to do both, right? So the context is arbitrary. It's an engineering problem, right?

[02:47:07] What's your problem? The problem I'm dealing with with my software that I write is that synchronization and validation of the data that makes a node, right, should scale. In other words, if I increase, say, all aspects of my hardware, increase bandwidth and memory, bus speed, SSD speed, and CPU threads and speed, if I have all those to choose from and I increase some or all of them, I should get a proportional rate increase of transfer of data and validation of data. If I do that with bitcoind, Bitcoin Core, there's nothing, there's not one single aspect or all aspects combined that will increase that throughput, not proportionally.

[02:47:55] So I'm working on scaling that factor that I defined for myself, which is I want to scale initial block download and validation, right? So that as Bitcoin grows in length, the linear chain, I'm not linearly increasing the time it takes to catch up with that chain, because eventually, it will become completely unusable. And as it stands now, on my machine that I do all my testing on, I have a linear increase in cost as the chain grows, where with Bitcoin Core, I have an exponential increase in cost.

[02:48:33] That's the difference between scaling and not scaling. It's not proportional. So when we talk about scaling Bitcoin, some people will say, I'm only talking about BTC. That's all I care about, OK? If you're going to talk about scaling transaction throughput through BTC, which is layer 1, right? BTC is BTC, right? It's the chain. I will tell you it is not possible. By design, it is absolutely not possible. And nobody's going to prove otherwise. It is absolutely not possible. If you're going to say, well, I want to scale the rate at which people can transact with a different security model than layer 1 and be able to settle on layer 1 when they're done doing that, that looks like Lightning or sidechains, right?

[02:49:22] That's not scaling layer 1. That's scaling the ability to transact at a certain rate using a different security model, right? It's close, which is why people get away with it, right? I understand. But OK, now, but that's just trying to scale BTC. If you're trying to scale Bitcoin in general, which means let all of the people in the world.

[02:49:42] John Carvalho: And I don't think anybody's trying to do that. Nobody is ever having that conversation. Only we when we're trying to describe dynamics. Let's

[02:49:49] Eric Voskuil: Take a theoretical, right? If I wanted to scale. Bitcoin, which is not lightning, which is not liquid, which is the security model of what we call layer 1, right? Not limited to any one chain. It could be the same rules, right? Maybe different mining algorithm again. And I wanted to scale this for the purpose of if more people want to transact at the same rate and at the same cost in general, we could add More hardware, and they could do that. That's what scaling means. So, so...

[02:50:24] John Carvalho: Can you, can you hear me now? Can you do the same trick on raising block size? In other words, you explained how Bitcoin cannot scale, and adding hardware or whatever doesn't achieve that. That's the problem. But doesn't it, though, in reverse? In other words, if you have a certain amount of throughput at one megabyte, let's say the blocks are always full, as the example, you have a certain amount of throughput at one megabyte and the blocks are always full, and then now you increase, in order to increase it, to two megabytes. No, no. So we go to two terabytes. You increase the hardware, you increase whatever amount, it doesn't matter. You increase the hardware requirements. Now, let

[02:51:05] Eric Voskuil: Me let me answer your question. I understand the question, right? So let's say we go from our four meg block limit, which we have now, right? And we say, okay, there's no limit, right? We're going to make sure we maintain a constant throughput of transact ability. And, again, remember, the first criteria was the same security model, right? The same security model as is inherent in Bitcoin. So that means I can hide when I transact. I can operate in secret. I don't need anybody's permission, right? It's a permissionless black market money.

[02:51:35] So we go from four megabyte, which you can run on the hardware today, fairly inexpensive hardware using the Bitcoin. You can get synced up in 39 minutes if you want to use assume valid, right? But then we go to accommodate everybody in the world. We just say, okay, well, it looks like it's going to be a couple of terabytes per block. So we do that, right? Now we've broken the security model. So it's not the same. Bitcoin cannot shard that data. You're muted. You're muted. Bitcoin can't shard its history.

[02:52:12] Now, I haven't proven this myself. I believe it to be true. But Peter Todd wrote what he believes is a proof of it, and nobody's disproven it, right? People tried and tried and tried to shard the chain, which means to break it up into pieces so you can operate over it independently. Well, guess what? If you take BTC 0, 1, 2, 3, 4, 5 as independent chains, which you do atomic swaps across, they are sharded by default, right? That's how it works. The only way to shard Bitcoin, as far as I know, is to separate the chains.

[02:52:42] And if you do that, you don't have to have all of the transactions for all of the people everywhere in the world. You may need to periodically transfer between one or the other. You may have limitations for who you can transact with.

[02:52:55] John Carvalho: I feel like we skipped over the answer, though, because you took it to an extreme of so many terabytes.

[02:53:03] That's the answer.

[02:53:04] You have no limit. Nobody's proposing an infinite block size.

[02:53:08] I didn't say infinite.

[02:53:09] Eric Voskuil: I said two terabytes.

[02:53:10] John Carvalho: My question is simply, in the context of describing scaling in the way that you've described it, how does going from four megabytes to five megabytes not constitute as scaling?

[02:53:25] Eric Voskuil: It's not proportional. You have a proportional decrease in security. You have a proportional decrease in security as you increase the- What is

[02:53:32] John Carvalho: The function of that? How do I know that?

[02:53:34] As I described before,

[02:53:35] Eric Voskuil: People are less able to operate in secret at the same cost. This is the whole reason why- You're

[02:53:43] John Carvalho: Making an assumption that you don't actually know the answer to, which is that those people can't afford the cost.

[02:53:51] Eric Voskuil: I'm making a reasonable engineering assumption that the cost of two terabyte blocks is much higher than the cost of-

[02:53:59] John Carvalho: But I didn't say two terabyte. I said a small- You're

[02:54:01] Eric Voskuil: Selectively choosing a low enough value that you think you can just sneak through. I'm selectively choosing a high enough value that makes the point.

[02:54:09] John Carvalho: But I'm not proposing the high value. I'm proposing the low value.

[02:54:12] Eric Voskuil: The point is that there is a limit, and you're proposing that there is no limit.

[02:54:17] John Carvalho: No, I'm not. I'm proposing- Yes, you are,

[02:54:19] Eric Voskuil: Because there is no point- I'm proposing that the limit can change,

[02:54:21] John Carvalho: Which it has changed.

[02:54:23] Eric Voskuil: You're not proposing any limit. What's the limit? Tell me what the limit is.

[02:54:27] John Carvalho: Eight megabytes.

[02:54:29] Eric Voskuil: Okay, so we go to eight megabyte blocks, and you're good forever. You're never going to change it. I mean,

[02:54:33] John Carvalho: Probably until I die.

[02:54:34] Eric Voskuil: No, we already did four, and we already went 4x, and you want to go 2x.

[02:54:40] John Carvalho: No, I don't want to do anything. This is theoretical. I'm trying to establish definitions. I'm trying to play the same quality as you require.

[02:54:48] Eric Voskuil: I'm making a point that the limit is arbitrary, and if you don't shard the data, you will hit an infeasibility limit. And the reason you will hit that is because there is no cost of putting data on the chain. You will fill it with low cost, nothing. It's already

[02:55:10] John Carvalho: Happened. I'm not actually proposing a block site increase, but if I were to, it would be under the conditions. In other words, I would be looking at the environment, and I would say, okay, the transaction fees are $1,000. I'm thinking about leaving Bitcoin and using Litecoin now because I can't afford Bitcoin, but I just don't want to do that. I think that because if the blocks are full all the time, and that's why they're $1,000, that if we made them 20% larger, that they may be a related decrease.

[02:55:42] The whole argument

[02:55:43] Eric Voskuil: Rests on this premise that it's just a little bit, right? And there's no just a little bit. This is an arbitrary

[02:55:49] John Carvalho: - Because the demand isn't infinite at any price. It's infinite at no price.

[02:55:56] Eric Voskuil: But the demand isn't ever inconsequential. The difference isn't ever inconsequential. It's disproportionate. I

[02:56:02] John Carvalho: Have no problem saying that it's consequential, and there would be an increase in cost. What I have a problem with is assuming that that cost actually has an impact. We don't know.

[02:56:12] Eric Voskuil: Of course we know. All you have to do is take increasing value, and you'll realize at some point it has an impact. If

[02:56:18] John Carvalho: My hamburger costs $10 or $10.01, it doesn't affect me, right?

[02:56:28] Eric Voskuil: Allow us to explain it to you. You're not proposing any limit. You will grow it indefinitely.

[02:56:36] John Carvalho: But I said no.

[02:56:37] You're changing what I said. I did not say that. No, I'm not. You can't. All right, let's specify it better. I'm proposing raising the block size every time it stays full for two years.

[02:56:50] Eric Voskuil: Who's making the decision? Which central authority is choosing this?

[02:56:55] John Carvalho: No, no. It's a hypothetical. Okay, well,

[02:56:58] Eric Voskuil: Let's resolve your problem with your design. Let's see who's going to do it.

[02:57:03] John Carvalho: I'm not talking about the challenges of activation. Who's going to decide that

[02:57:06] Eric Voskuil: It's cheap enough for everybody to run this coin in the jungles of fucking Myanmar? Who's making that decision? Coinbase? Well, I

[02:57:16] John Carvalho: Don't know. If it costs, say, $2 a year to run Bitcoin, and we make it $2.05 a year, how many people will that meaningfully affect? Probably in practice, not very many.

[02:57:27] Eric Voskuil: Okay, you're suggesting that we make it. Who's the we? How did the decision get made?

[02:57:31] John Carvalho: Well, you know who the we is. The we is Bitcoin Core, and they make it arbitrarily themselves. I think

[02:57:35] Eric Voskuil: It's Coinbase and Saylor and all these guys who are basically going to pull all the strings and going to say, we decided it's this. It's a terabyte per block, and we can run that without any problem. And we don't really care about your black market use cases because we're a white market business, and we don't want this illegal money laundering stuff happening. But I don't think that

[02:57:54] John Carvalho: People don't know Bitcoin. You're opening the door. I don't think cost is the main reason that people don't know

[02:57:58] Eric Voskuil: Bitcoin. If your whole system depends on people coming to agreement without Bitcoin. The whole point of Bitcoin is people come to agreement without any central authority. It's not a voting process. I

[02:58:10] John Carvalho: Have no issue agreeing that changing Bitcoin is an oppressive, very... So your whole premise

[02:58:17] Eric Voskuil: Is that you're going to change Bitcoin using some agreement on a regular basis to decide what's the optimal size that everybody... I don't need

[02:58:28] John Carvalho: A specification for it. All I can say is that if the market were to demand it and we were able to provide it, that if that happened, would that not be an increase in throughput by increasing hardware requirements?

[02:58:42] Eric Voskuil: We've already done it, right?

[02:58:44] John Carvalho: We've already done it. And on average, the blocks have been larger than one megabyte. Yeah, yeah, significantly. So that wasn't scaling?

[02:58:53] Eric Voskuil: Well, it takes significantly longer to sync than it would have, yes. It's a negative scaling factor, right? You've increased... Well,

[02:59:02] John Carvalho: Only if you consider scaling to be the time it takes to sync the blockchain.

[02:59:07] Eric Voskuil: Or to validate, right? Eventually you get to the point where nobody can catch up. That's where you'll get.

[02:59:12] John Carvalho: I agree on that. In other words, I think that there is a size that's too much. But I think that we... It's arbitrary.

[02:59:19] Eric Voskuil: You will hit it at some point, and then what will you do?

[02:59:24] John Carvalho: Well, you avoid hitting it.

[02:59:26] Eric Voskuil: We won't be able to avoid it. So you're

[02:59:28] John Carvalho: Saying, well, we rose it once. Do you think that means we hit it?

[02:59:33] Eric Voskuil: I'm saying you will hit it at some point if you achieve... If the world achieves this, everybody in the world is using Bitcoin, which people fantasize about, right?

[02:59:42] John Carvalho: That's not what I'm proposing.

[02:59:44] Eric Voskuil: But again, this is what people imagine as scaling. You know, hyper-Bitcoinization, everybody's using it for everything, everywhere. It takes over all banking, it takes over all governments, and we're all using Bitcoin. What's the throughput? Right? It's a fantasy. Block size increases are not...

[03:00:01] John Carvalho: I guess the way I see it more is, what if only 20% of the world ever really wants to use Bitcoin, and we have 18% of the world now, why wouldn't we scale to be able to support the 20%?

[03:00:14] Eric Voskuil: We don't need to do anything. If those are the numbers now, we don't need to do anything.

[03:00:20] John Carvalho: Again, this is still the hypothetical where it's like, you know, that you have excluded people due to costs of the transaction more than you've excluded people due to the cost.

[03:00:31] Eric Voskuil: It's already been done. It can happen again. I'm not saying it can't. But I'm saying that if our solution to scaling is just to continue to grow the block size, it will fail. That's how it will fail. People will not be able to [unclear: see that].

[03:00:43] John Carvalho: I know there's a lot of nuance here. I mean, how many are we talking about, like doing this for like the next two years or the next 200 years? Because I'm not talking about doing this. I'm not talking about doing this until it feels like Bitcoin is full and now is losing value because people are getting fed up with it being full.

[03:00:58] Eric Voskuil: Remember that Bitcoin, that we're talking about scaling, requires all transactions from the beginning of time to all be validated by the person who's trusting it. So we go 100, 200, 500 years in the future, are you really talking about we're going to just put arbitrarily large blocks together and people are still going to be able to do that?

[03:01:20] John Carvalho: No. I don't think Bitcoin will be around 100 years in the future, 200 years in the future. I think we have to work with what we have.

[03:01:29] Eric Voskuil: We're going to break what we have, if we don't figure out how this works. That's my point. And it already works. There's no need to propose something that clearly will fail at some point in the future. All we have to do is shard the data

[03:01:44] John Carvalho: Out of the box. I hope you appreciate that. I am playing devil's advocate and having a theoretical conversation. I have no intentions of proposing a block size.

[03:01:49] Eric Voskuil: Imagine what happens if what happens is what I'm suggesting has already happened and will continue to happen. Let's say Bitcoin overflows into Litecoin, Bitcoin gets super expensive, and nobody's really transacting on it, and everybody just starts moving all their money over. Again, these distinctions are arbitrary. I'm not trying to promote Litecoin. It's just the only other reasonable coin that I know of. They just move. It's a good example. Everybody moves over there. Maybe it's quantum resistance. Everything's got to move anyway. So all the money moves on to some- and guess what that means?

[03:02:27] We don't have to validate that history anymore. It's gone. People can if they want to. It's not really growing anymore. They can validate, but that becomes historical data. We can set that aside and get rid of it. So now we can actually, for real, prune. The pruning we talked about today is bullshit. The pruning we talked about today is nobody will be able to validate because we've pruned. If you can take an entire chain and set it aside, and nobody needs to download it except for maybe the one guy who's still got a little money on there, who probably has lost it all at that point.

[03:02:59] So the naturally occurring approach using nothing but Bitcoin already solves these problems. You raised a reasonable concern or question about exchange price. Now, I'm not talking about centralized exchange. I'm talking about the trading price between two people when they're doing an atomic swap. But anytime anybody buys something with Bitcoin to buy that chainsaw, I have to know what my Bitcoin is worth. I can either just decide for myself what I think it's worth. I think it's worth a million USD per coin. OK, well, I'm not buying that chainsaw for one Bitcoin.

[03:03:39] But everybody has to know that somehow. How do they know that? Who knows? That's not inherent in the protocol. But that isn't a different issue when it comes to atomic swaps. It's just they have to know it on both chains. That's all. So I don't really see where it's going to stop happening. So it's like I'm not really the guy proposing this is a BIP and this is what we do. I'm just pointing out it already happens. It's not subject to the scaling limitations of just continuous block size increases.

[03:04:15] It solves the sharding problem and the eventual ability to get off of historical data. And it doesn't require a complex new or different implementation. And in this scenario that I'm describing, something like Bitcoin could run any number of chains with the one binary. Doesn't have to recompile. So simple as well. And simple for all things being equal, simple wins. And that's why I was saying, well, what's the advantage of the lightning system, which not only has software complexity, but has runtime complexity and runtime centralization force?

[03:04:59] Watchtowers. And exit problems, things like that. I don't even have to explain to you what I'm describing. And

[03:05:10] John Carvalho: We established this since the beginning of the interview. I think maybe a lot of the dissonance comes simply that most Bitcoiners, even the engineers mostly, want to have intact the number go up aspect. That's it.

[03:05:24] Eric Voskuil: That's the only answer. NGU. That's why it doesn't happen.

[03:05:29] John Carvalho: But it does happen. But that's not worthless. In other words, it's not just about speculation. There is a utility

[03:05:33] Eric Voskuil: To that as well. I'm not saying that it's worthless. I don't want to imply that at all. But if that becomes the consideration that prevents us from exploring viable alternatives to what we've been exploring, then that's a problem. And of course, people have to use it, have to have demand for it, or it's not secure. And if they don't demand more than what we have in, say, BTC, we don't need anything more. We don't need a block size increase. We don't need another coin. We don't need to leave in Lightning. But if they do demand more, that means that the number is up high enough to provide security for overflow into another chain, for example.

[03:06:12] Once it gets to some point, it will be there. And that already does happen. So it's observable. There's sufficient demand, numbers up high enough in BTC to drive...

[03:06:24] John Carvalho: You don't also want that, though? In other words, you work in Bitcoin, you hold some Bitcoin to some proportion of your assets, whether it only be a proportion just for using as black market money or an investment or, you know, sorry, that's the wrong word. Speculation...

[03:06:41] Eric Voskuil: It's a money.

[03:06:44] John Carvalho: But isn't there a utility to being able to say, for example, if I lock this into a Lightning channel and spend it, then my base is Bitcoin exposure, whereas I don't want Ethereum exposure because I think Ethereum might die.

[03:07:01] Eric Voskuil: Well, Ethereum's not a Bitcoin. It doesn't have the properties of Bitcoin. It's not... Right. So personally, I retired before Bitcoin existed. So I didn't come to this as a speculator. I came to this because I wanted something to do in my retirement or maybe a next business that would be compelling enough for me to work on for that amount of time. I ended up having some because I work in it, and it's convenient, and I have to know how it operates. I've never, ever promoted it as a way to get wealthy or speculation or an investment.

[03:07:41] And you know this, right? You read anything I've ever written about it. Never in 11 years of this have I ever said, you know, Bitcoin is a way to get rich or to make money. It's a money. Monies don't make money, apart from speculation on price changes, which means you know more than everybody else about what the right price is, which is irrational from an economic standpoint.

[03:08:05] So I don't care about that. All I care about is that Bitcoin has enough demand that it can exist and be secure enough for people to use it for what they want to use it for. And I think it's way beyond that level of security. So whatever. Do I care about states using it? No. I think that's, at best, neutral. More likely, it's potentially very harmful to the security model.

[03:08:42] So yeah, no, the answer is it's not why I'm here. I don't care.

[03:08:49] John Carvalho: Yeah, that's where all of the dissonance and all of your Twitter arguments comes from. It's just there are people who are trying to operate from a position of optimizing the throughput of Bitcoin BTC. And then there are people like you just trying to enforce the dynamics as you understand. Well,

[03:09:06] Eric Voskuil: The thing is that those people that are trying to do the engineering work are doing what you're saying. They're trying to pump their own bags, right? Whether they say it or will admit it or not. I mean, I have to say, you know, one of the most, I mean, shouldn't hold up people to be heroes of any kind, right? But personally, I found it a little disappointing to watch Adam become nothing but really a speculator

[03:09:37] John Carvalho: From what I can see. You and everybody else. It's like a thing that people talk about at conferences when they bump into each other. I'm so disappointed he's always speculating.

[03:09:47] Eric Voskuil: But I tried to caveat that with, okay, maybe it's just I didn't know him, and that's who he is, right? It's fine. But it's like, we all have this sense, like, what's going on here, right? Like, okay, but maybe that's just, we just made an assumption about him that wasn't true. Okay, great. Maybe his objective had nothing to do with being a cypherpunk for all this stuff, and the only reason he's really into that is because he wants to see the price go up. I'm okay with that.

[03:10:13] Saylor can do what he wants. They can all do their thing. That's the whole point. Everybody can do whatever they want with their own money. They can mine what they want. They can write any software they want. That's fine. But I don't find it very interesting, and I don't like it when people whose true objective, which I know some people whose their true objective is to pump their number, will come out and argue for technical issues without being upfront about that. It's like failure to disclose, right?

[03:10:39] What's my conflict of interest? Got a lot of people working in Bitcoin in various ways that have a very big conflict of interest in that they own Bitcoin, and it doesn't necessarily lead to the best decisions being made if your objective is more on the cypherpunk side of things, where we're trying to enable disempowered people to be able to keep some more of their own money in the face of their state, being able to send money to their relatives who are being oppressed in Venezuela or wherever, or to reduce their crazy tax loads.

[03:11:19] And for the most part in the West, our problems are rich people problems. And no matter how much we bitch and moan, you look at the rest of the world. And so I'm not working for like Adam, who's British, to pump his bags. I don't care. I'm not pumping. I'm not working to grow my bag. And I'm not working to grow anybody I know in Bitcoin is not in a position where they really are going to just die if their bags don't grow, right? It's just not a very common scenario.

[03:11:49] John Carvalho: So an interesting conclusion here is, anyone promoting scaling of Bitcoin is focused on speculation.

[03:11:58] Eric Voskuil: No, I'm not saying that. I'm saying it's a very- I'm proposing

[03:12:02] John Carvalho: It. Would say that that's a fair conclusion? No, no.

[03:12:05] Eric Voskuil: I believe that a significant aspect of Bitcoin development and promotion centers around this idea of keeping BTC the only coin, everything else is a shit coin, demonize all the people, all the software, everything, right? That is about pumping your own bags. And the people who are honest have told me that.

[03:12:28] John Carvalho: But what's the difference between scaling- oh, sorry. What's the difference between scaling BTC, not Bitcoin, scaling BTC and speculating and promoting speculation? There is no functional difference, according to you.

[03:12:42] Eric Voskuil: No, that's not true. I'm just saying BTC won't scale. It doesn't scale. So it's really moot, right?

[03:12:47] John Carvalho: Right. So the people working on it are simply trying to keep everything in Bitcoin.

[03:12:51] Eric Voskuil: Right. And they're just- Because their numbers

[03:12:53] John Carvalho: Go up.

[03:12:54] Eric Voskuil: Right. And again, I've been told that directly by some of these people years ago, way before even maximalism was becoming a thing, right? It was like, just getting started. And I'm like, what's really going on here? And that's the person who's being honest, who's saying like, we want to kill all shit coins. So you can come out and say, we want to save people from scammers. OK. So take the Milei thing, I don't know what happened, Argentina, whatever. At this day and age, at this point in time, who is putting their money into some fucking meme coin shitcoin?

[03:13:27] Speculators. Not mom and pop. They don't even know how this stuff worked.

[03:13:30] John Carvalho: And no one- Yeah, they all want to pretend like somebody did something to them,

[03:13:33] Eric Voskuil: But they signed up for it. But nobody's getting scammed anymore. Maybe in the beginning, maybe even with BCH, but they're not getting scammed. They're gambling. And I don't give a fuck if they win or lose. I don't care, right? And so this idea, this kind of white hat idea of Maxis that they're saving the world from these scammers, if it was ever real, it's no longer real. Let the buyer beware. Everybody's responsible for their own money. And if enough people get scammed, which has happened time and time again, at some point, you realize they're gambling. It's not because they're ignorant.

[03:14:15] And I've never complained about Maxis or anybody educating people about how these things work. I call things shit coins if they pretend to have the security of Bitcoin and are not based on the same security model. I call Ethereum a shit coin because it's proof of nothing else. It's because it's proof of stake. I

[03:14:36] John Carvalho: Think most Bitcoiners call shit coins shit coins because they're lower on the spectrum.

[03:14:40] Eric Voskuil: They call them shit coins because they're not Bitcoin, not BTC. And some have been very explicit about that. Anything but BTC is a shit coin. I'm like, well, OK, but BTC could have been Litecoin. There was nothing in the paper. Litecoin didn't deviate any way from the paper. Well, it did.

[03:14:57] Vlad Costea: I'm sorry to intervene at this point, but also the conversation about scaling seems a bit dated because what Litecoin did was to add extension blocks with Mimblewimble. And what Mimblewimble does beyond the promise of privacy is to prune previous transactions. So it scales very beautifully. They can actually increase the block size of the extension block with soft forks. They don't need to touch the base layer anymore and they can onboard people on the extension block. So I'm surprised that this is not a bigger conversation in Bitcoin because it works really nice.

[03:15:35] There are transactions on the extension block which are collected by the miners. So it does solve part of the incentive problem with mining. They're also merge-mined with Dogecoin and that's another can of worms. But my point is that there's this Mimblewimble thing which scales pretty well and you can add that to Bitcoin with just a soft fork.

[03:15:59] Eric Voskuil: So I don't all my comments on Litecoin predate. I'm aware of the Mimblewimble thing, but all my comments on Litecoin predate that. I'm just using it as a stand-in for another implementation of the white paper. So in that case, it wouldn't really be, but that is not my intent. So if we take, say, BTC and change the genesis block or even not but change the mining algorithm and run two chains side by side, that's what I'm talking about when I refer to Litecoin. There's definitely a valid Bitcoin implementation that wasn't the one that we got.

[03:16:38] And that's just your pure probability. Block one could have been a totally different block. We have an entirely different history. It's just probability. It's clearly the case that there can be more than one. Now, Maxis will argue that the one that everybody uses and the one that came first, which again, could have been any number, is the one we should all gather around, because that's what makes it secure. And everything else is an attempt to steal or something from that, which is ridiculous. It's your own money.

[03:17:15] And so it's just a disingenuous argument. And I remember making these comments to Adam like a decade ago. I remember saying a couple of times, isn't the whole point of Bitcoin that you get to do what you want with your own money? And we're telling people that they're criminals, right? They're criminal fraudsters for just mining a different coin or spending a different coin with their own money, their own boxes, with other people that voluntarily want to do it. So to me,

[03:17:48] John Carvalho: That was the core. I think that there is some cultural excuses for that, though. There was a time, and it hasn't, there was a time when altcoins were innocent, like Litecoin, and we had an experimental. And then there was a time very shortly after that where they became extremely exploitative. And then we got ICOs and DeFi. And there's just so much exploitation.

[03:18:11] And that was kind of past that hump to where it's all normalized, which is what you were pointing out earlier.

[03:18:17] Vlad Costea: No, it's not. I'm not sure if you watch the news, but Kanye West is sort of reigniting the meme coin market right now.

[03:18:26] Eric Voskuil: Whatever. I don't care, right? Like, go to Vegas. It doesn't matter. When

[03:18:29] John Carvalho: I say normalize, what I meant is that how Eric was pointing out that like, nobody's really getting scammed anymore. They all know that these are like, Right. They're getting

[03:18:37] Eric Voskuil: That they can get in and out before everybody else. And you know, like, for all I know, you know, the Trump coin was just a way for a bunch of fanboys to donate, right? Just give them money because they're, who knows? I don't care. Do whatever you want. I'm only working on Bitcoin. I don't care what you do. So my point was one of theory, right? Not one of practice. I know that there are legitimate scams and fraudsters that are out there lying about this, that, any other thing.

[03:19:09] And there are shit coins that may or may not be scams. They may just be stupid people who are thinking they have a secure whatever thing based on Bitcoin. There are people that run in scams. Shit coins if they're not, to me, they're shit coins if they pretend to be Bitcoin and they're not. And in order to define that, I pulled out what I thought were the, you know, looking at how Bitcoin operates, the essential aspects from the paper and the implementation of how Bitcoin works and how it secures, how it's secured.

[03:19:37] And if something pretends to do that and doesn't, I call it a shit coin. But clearly, theoretically, right, there are no limit to the number of valid, legitimate, non-shit coin implementations of Bitcoin. Even the chain that we have, there's an infinite number of other possibilities that could have occurred with the same genesis block, same rules, everything.

[03:20:01] So, well, not infinite. But it's an awful big number. Clearly, from that standpoint, it's disingenuous if you understand that. People I'm talking about did understand that and just said, but I want my number to go up. That's how I've looked at the whole thing. It's like you're telling everybody that anybody that's doing anything other than BTC is a fraud and therefore a criminal, but the whole point of this Bitcoin stuff is to do what you want with your own stuff, and somebody making their own coin and trading it with other people and mining it and doing whatever they do, even if they fork off of BTC, all they're doing is taking their own hash rate and using it in some other way, which is perfectly well within their rights to do it.

[03:20:51] Just as an aside, I'm very careful when I use the word attack. It's very heavily overloaded in computing and in Bitcoin in general, but I don't use the word attack when I refer to majority hash power censorship enforcement, which is what happens when we do soft fork enforcement. It's majority hash power censorship. I use the term censorship through majority hash power. It would be a 51% attack if somebody stole from somebody. Attack implies a crime, a theft, and it's an attack if I say, I go get that chainsaw, and I give you the Bitcoin, and then I mine to reverse my transaction using majority hash power, and I keep the chainsaw.

[03:21:34] I had intent to steal, and I did it. That's an attack, Finney attack, 51% attack. Doing what you want, not mining blocks you don't like is not an attack. It's censorship. Censorship by the state using money that they stole, maybe you could consider that an attack, but every miner censors. Nobody has an obligation to mine anything.

[03:22:02] Censors in the sense they selectively choose which transactions go in and out because there's no objective way to do it. It's not feasible. There is no clear line where you can say, you have to do this with your hash power. You have to do this with your money. You have to join us. You can't leave and co-create your own coin or split off and be your own coin. I always saw that as bullshit. I remember saying that to Adam saying like, isn't this the whole point?

[03:22:28] There's no good answer to that. It's like, well, yeah, but these people are frauds. They're like, no, it's not a fraud to mine your own coin. But I think in this day and age...

[03:22:38] John Carvalho: Sorry, what I was going to say, from like a sociological level, though, is it worth analyzing? Maybe the design of Bitcoin works because people speculate on it, and something about the design forces this behavior because it's so prominent, like 99% of people are in it for this.

[03:23:00] Eric Voskuil: Right, right. Again, you're free to speculate. It's fine. It may be necessary for it to get to a certain point. That's also fine. Everybody speculates on everything. We have to guess what price is going to be, whatever.

[03:23:19] The basis of speculation is the idea that the current price is wrong, which economically is irrational, because the current price incorporates all knowledge that there is about the future as well. People do it, but it's a zero-sum game, to the extent that people win, other people lose. There's no production. There's no growth. Trade is positive-sum. Production is positive-sum. Speculation, to me, is just neutral. It's not why I'm here. I don't say people shouldn't do it. I don't do that. I just caution people that money is not an investment.

[03:23:57] It doesn't produce. There's no guarantee of yield. Investments, if you index the entire world's markets over time, you're going to earn whatever the time preference is. If that didn't happen, everybody would be dead. Production has to be positive return or there's nothing produced. Yield interest is just the return on production. There's a big difference. I point that out, but I never tell people they're bad for doing it. I do call people out for calling other people bad for doing what they want with their own stuff. Their money, you don't have to mine your coin.

[03:24:35] If somebody wants to go off and mine BCH or mine SegWit2x or whatever, that's fine. If you can't gather enough people to mine what you're selling, then it doesn't work. But nobody has any obligation to anybody else in this system. The fact that it works is tremendous. People speculate. People want it for different reasons. Cypherpunks and whatever, it all works. I think that if the only reason we're doing it, or if the only reason we're talking about development making decisions or people making decisions is to make the number go up, then we're going to lose sight of the value proposition, which

[03:25:22] John Carvalho: We already are losing sight, I think.

[03:25:24] Eric Voskuil: I think it's widely understood at this point that there's something going wrong. When I saw the hordes of people doing the Saylor dance, especially people that should know better, again, it was like seeing the Adam thing. It's a little disappointing. They can do what they want, but I thought we were in this together.

[03:25:50] John Carvalho: I wanted to ask you, using your economic skills and ability to rationalize things, are you interested or are you able to speculate on what you think the most likely outcome will be for Michael Saylor and what he's doing, and the investors of his stock?

[03:26:10] Eric Voskuil: Have you ever looked at the history of his company?

[03:26:14] John Carvalho: I know it's been around for a long time. It was a failure for a long time. I think

[03:26:19] Eric Voskuil: He holds the dubious distinction of having lost more money overnight than any company in history.

[03:26:28] John Carvalho: He's trying to beat that, you think?

[03:26:31] Eric Voskuil: That's actually true.

[03:26:35] He's a wild speculator. As far as I can tell, the company never really produced anything significant. Certainly, over a 20-year stretch, it was flat. So that's a lot of loss. And now, he's gone all in on speculation. But it's like speculation, you can be a big win or you can be a big lose. And it's like Soros that speculated for gold against the British pound, and that's where his money came from. So one big win, and you're all set. So it might work out. I understand the game he's playing.

[03:27:14] I was a board member of several companies. I've seen how a company that's big enough can borrow from the taxpayer, fundamentally borrowing from the taxpayer at low rates, and use that money to earn over time and pay it back at low rates and pocket the difference. I've even seen that done where the money that's borrowed is issued directly as a dividend, directly. So borrow it, 0.5%, issue a dividend that the shareholders can then invest and earn an average of, say, 9% to 10% per year by just indexing the markets.

[03:27:53] And where did that money come from? Where did that difference come from? That's just playing arbitrage with the Fed. And the Fed taxes that money out of people's savings. So that's what he's doing. He's borrowing at below market rates in order to speculate. So the return could be much higher. It could be much lower. But even if you just put it in the market index, you'd still be making money. And that all depends on whether you have access to taxpayer money.

[03:28:25] So as long as price goes up enough or doesn't go down enough, you'll probably be fine. Just keep doing it until everybody starts doing it.

[03:28:35] John Carvalho: They start giving away. I don't follow it closely enough. And I haven't figured it out yet. But I feel like there's something much worse going on. In other words, where it must implode at some point because of some sort of force that he's winding up in the market and making himself a target. Because all of that Bitcoin, all of that, he's using the loans to buy the Bitcoin. And then he has Bitcoiners buying the stock instead of buying the Bitcoin. And this feels like winding up a toy for it to explode.

[03:29:11] Yeah,

[03:29:12] Eric Voskuil: I understand what you're saying. But I personally can't put my finger on what that issue might be. So I don't want to put any bad info out there.

[03:29:23] John Carvalho: It just feels instinctive. I'm just like, no, this can't work. There's something that's going to implode here.

[03:29:29] Eric Voskuil: But I can say that if you just did arbitrage, basically interest rate arbitrage, sure. As long as you can get, I mean, just by indexing the market, over 25 years of just indexing the markets, I've earned an average of 9.5%, 10% a year. And that's what you would expect through historical returns and total US market. Europe, on the other hand, flat for 20 years. Well, maybe not flat, but like 9% over 20 years versus 9% per year over 20 years. So big difference.

[03:30:00] But if you just did that, if you just borrowed money, invested it, borrowed money, invested it, paid it back, you're just doing arbitrage between, say, 1% and 9% or 10%. That's a lot of, you know, that's what member banks do with the Federal Reserve. They borrow money.

[03:30:15] John Carvalho: But he's not doing that, right? Because he has like, he has a buy-in price, a price average that he's entered, he has a price of his stock that's variable as well. Right.

[03:30:24] Eric Voskuil: It's more complex than that, right? Yeah.

[03:30:26] I get it. And same thing with banks. It's more complex, but the basic principle with banks, right, is you borrow from the Fed at a tiny fraction of a percent, and you lend for a home improvement loan at 10%, credit card loans at whatever. Right? So you make the interest rate difference without having any capital of your own, because you're able to get it from the Fed, which gets it from the Treasury, which is printed, which is, therefore, seigniorage, which is taking money out of people's pockets.

[03:30:56] John Carvalho: Well, there's also the fact that he sells his own shares of MSTR as well. And so, like, what he's doing personally is a separate topic.

[03:31:05] Eric Voskuil: Well, yeah. You're smart to get out as it's going up. But yeah, I have a feeling it's not going to end well. But I also have a feeling he's probably going to pocket quite a bit before it ends badly, if he's doing what you're saying.

[03:31:24] John Carvalho: Well, he says he's never going to sell.

[03:31:26] Eric Voskuil: He's never going to sell. That, I can say, for sure, is bullshit, because the only point of having him is the seller. I just

[03:31:32] John Carvalho: Can't imagine. I don't know what his board structure is, but I just can't imagine him, like, with a straight face, suffering his shareholders and his board, having not sold anything during the boom. I thought he

[03:31:42] Eric Voskuil: Had controlling ownership.

[03:31:44] John Carvalho: So... That might, yeah, maybe that's why that won't happen then. But it just seems like, how could you live with yourself leaving $20 billion on the table

[03:31:53] Eric Voskuil: Or something? Well, here we are with the potential hypocrisy of the Maxi crowd that was cheering for Saylor, [unclear: and Patel], maybe more recently. Because it was all about number go up, and because he was driving that number up, yay, and then turns around into a scammer, right? Or yay, Trump coin, yeah, scammer, or National Reserve, whatever we were talking about last. It's like one bad follow after another. So I try not to have too many, I try not to do too much cheerleading, have too many heroes that tend to let you down.

[03:32:31] So I don't know, to me, it may be beneficial that it brings in development money. That's the number going up, and it may be beneficial from a security standpoint, drives interest, all these things. Again, I don't tell people not to do it. It's just not the end goal. And if we lose sight of the end goal, right, if we could take advantage of all that capital coming in and do things that make sense towards kind of a cypherpunk objective, great. But that's not really what I see so much.

[03:33:00] I see that all that capital flows in, and we do stupid shit that doesn't make sense, like Chia, or risk-free rate of return, or like liquid, or whatever, right? Like, OK, we took all the kind of best core developers, brought them to Blockstream to do sidechains, said, no, we're not going to do that. We'll rent some time on a satellite, and we'll make a centralized federated whatever, and we'll make a redundant little mining thing. I don't know. Where did all that goodwill and capital go?

[03:33:35] John Carvalho: I had a lot of hope for Blockstream. When they formed, I thought they were going to be like the superstar Bitcoin company. And I was like, oh, this is so cool. And then they came out with financial products, and then they couldn't figure out the side chain thing the real way, and so they made a federation.

[03:33:51] Eric Voskuil: Well, maybe it wasn't ever going to work the real way. I don't know. I never got...

[03:33:55] John Carvalho: Nobody figured it out since then either, so.

[03:33:58] Eric Voskuil: So a lot of hype, a lot of money, and in the end, it's getting kind of disappointing. I've never been like an anti-Blockstream guy. I don't really hate the core developers. I have my specific issues, but it's just kind of disappointing. And I look at even their... I use their Block Explorer sometimes, because there's some aspects about it I like, but it's the slowest goddamn fucking Block Explorer you could possibly make. And I'm like, okay, so where's the value add from all this, again, all this goodwill?

[03:34:30] John Carvalho: I just don't... And you can just run mempools now anyway. Mempool.space has their own.

[03:34:40] Vlad Costea: I actually have a conspiracy theory about Blockstream. And I know I'm not the only one, because there are a bunch of crazies out there, a lot of schizos and whatever. But basically, what did Blockstream accomplish that they actually did well? They're the ones that pushed the two soft forks that Bitcoin got since 2017. So if anything, what can they present to their investors and say, you know, we are the ones that actually produced something. Yeah, I mean, they're developers. They made SegWit and they made Taproot. And maybe that the investors believe that they are the ones who politically control which piece of code is going to get into Bitcoin Core next.

[03:35:20] Eric Voskuil: Well, their developers did it. I don't think it was exclusively Blockstream. The developers that did it were the ones that, from what I followed, were the ones that had built reputation prior to Blockstream to be able to drive that kind of general agreement.

[03:35:36] And I don't see that really as an accomplishment of the company. It's the community that did that. And they probably would have done that or something similar without Blockstream.

[03:35:48] Vlad Costea: But they can also block, pun intended, some other proposals. If you go to, there is a Telegram chat that's called Cult of the Covenant. And that's where they were discussing CTV. And like two years ago, I think, no, three years ago, Adam Back joined the chat and basically destroyed their morale. He made fun of them. He did that, just one guy. He joined and he basically destroyed all of their plans.

[03:36:19] John Carvalho: I find it so difficult to get Adam to commit to, you know, a stance on something. Like if there's a, you know, position or a current hot topic and you try to talk to him about it on Twitter, you can never tell whether he's agreeing with you or the other side. He's very, you know, even handed or wishy washy. Yeah.

[03:36:40] Vlad Costea: He's trying to be this paternal figure who's trying to get everyone to agree on topics and he doesn't take sides and whatever. I

[03:36:49] John Carvalho: Recall him telling me in private, I think, in the past, not that it was meant to be a private conversation so much. It was just me and him that were there. It was at a conference or something. And I think maybe I remember it being that he considers his influence to be too strong to take a public position on things.

[03:37:06] Eric Voskuil: I mean, I kind of appreciate his demeanor in general. I think he's fairly level-headed and everything. It's just that, and, you know, he does get involved in technical questions sometimes when they're in his area of expertise. But for the most part, you know, the excessive pumping is just really tedious. And I don't, you know, that's, I'm sorry, I shouldn't really judge, right? He's free to do what he wants. But I just haven't seen, not just them, right? It's anybody out there. I just really haven't seen anything significant, right?

[03:37:47] And I don't really need to see anything significant. It's like, you know, I'm just working on making the existing, whatever the rules are, making them go fast. What

[03:37:57] Vlad Costea: They did with CTV was very suspicious because it seemed like a coordinated attack. On one hand, you had Adam Back destroy everyone in the chat. On the other hand, you had Grubles posting memes that were making fun of Jeremy. I mean, Jeremy Rubin. But people have

[03:38:13] Eric Voskuil: To be able to build their own, you know, they have to be able to build against that or without that. If they can't, then they're just not strong enough. And that's just one of the reasons why Amir created the BIP system, and it's one of the reasons why he created libbitcoin, right? It's one of the reasons why I continue to push at this. The reason I want, you know, one of the reasons I want to make a good node that's scalable and where people can understand the code and it's resilient and well-factored and all these great things we can get out of it is because there needs to be another center of expertise and excellence apart from core because clearly, and despite what they will say, if you don't toe the line, you're marginalized.

[03:39:00] And you guys have said several times, you know, if they don't agree, whoever they are, right, it doesn't happen. Or if they want to do it, it happens. That's because they control the software. And there's no reason for that except for the fact it's just been a better implementation than anything available. And when I look at it, I don't, you know, it's not like a challenge to make a better implementation aside from that it takes time. And eventually, you know, that won't be a power center anymore, just like Mosaic turning into Netscape was a big power center in the web, right?

[03:39:36] It kind of drove everything initially. And then they didn't because competition came along. And it was also about standards, right, and what direction we were going to go in terms of the web. It was a big deal. And I think that, you know, I saw that as kind of inevitable. It's one of the reasons I kept working on libbitcoin. And I've been happy with the outcome. And I think eventually, we're going to have other centers of excellence that don't depend on the ability to check in code into their repo.

[03:40:08] I don't expect... Core has

[03:40:10] John Carvalho: Been a bit divisive in how they portray your project as well, though. They haven't exactly been fair play. Sure, yeah.

[03:40:16] Eric Voskuil: But I don't give a fuck, right? Like, they don't have any control over me. I, you know, I pay for myself. I sometimes raise money for other people. I've paid other people myself to work on it. And I've done that for 11 years. And, you know, they can say whatever the fuck they want, right? I just don't, I don't have to listen to them.

[03:40:34] John Carvalho: And that's not true. Would love to see it grow to be more. I don't know what it would take for that to happen, for sure. But I just like the idea of there being competition implementations because it would make soft forks harder. I want more control and more stability over Bitcoin. Look at one

[03:40:52] Eric Voskuil: Of the things that happened. This is a little thing. I'm going to have it recently. So every once in a while, I'll push out a number here and there. I try not to overpromote early, like Amir would do. Right? It's like, like, there's, there's, there's, you know, it's been a lot to do. We're getting we're getting further along. But I pushed out like, because somebody was I asking, I pushed out some numbers. And then I went and bought a little computer, because he was like, it won't work on a small, because I did it.

[03:41:17] And I was like, wow, I was surprised. It was better than I thought. And he's been working with us now, because he got turned. But in that whole thing, people started to notice. There was a big flurry of activity. Several core developers started engaging. There's a thread on Delving. A couple of them joined our Slack for a period. One of them did a weekly thing where they do code review. They were reviewing our code. And somebody told me, so I went and joined it. So there was this big flurry of activity, because I think, one, they thought the numbers were bullshit.

[03:41:54] Nobody took, you know, so I'll give you some example numbers. On the machine I'm talking on now, which is at least eight years old, Dell workstation, 32 dual cores, 2 gigahertz, something like that, 1.5, 256 gig of RAM, PCIe 3, recent SSD. So kind of bulky, but slowish on the machine. My best equivalent to assume valid full sync time off the internet, 2.3 is what I measure gigabits per second cable internet. 37 minutes is my best time to fully index all transactions and all spends and do sufficient level of validation to achieve the equivalent of assume valid up to block 850,000.

[03:42:51] Bitcoin Core on this machine, same machine, takes 24 hours. This machine does not have SHA-NI, which is hardware-based hash acceleration, SHA hash acceleration. So what happens is, because it's, you know, Bitcoin Core has some multi-threading, right? But it's not a parallel execution, it's not scalable. So when you slow down hashing, everything slows down proportionally, and it's five times slower at hashing, right? But me, 64 cores. I just use more cores, right? 37 minutes.

[03:43:26] John Carvalho: Actually, I'm sorry. Any time I access Bitcoin Core on a desktop, you know, it's like, it feels like I'm literally opening an app from 2009. Like, it just, it's always super slow, it hangs, you know what I mean? It doesn't access the app while it's hanging. It's obviously a very, very old application.

[03:43:44] Eric Voskuil: So I'm going to correct something I said for the record. On this machine, it's not 37 minutes. On this machine, it's like 50 minutes. Core is, I think, 24 hours. On my $350 machine I got from Temu with Windows, which is 32 gig PCI 4, eight dual cores, fairly small cheap machine, that's 37 minutes, has SHA-NI and AVX2. So on that machine, Core takes 14 hours. Of course, slower on Windows. I think it's like 10 hours on Linux. So there's a significant difference. And the argument that you could tell, like the messaging that was coming out of some of the people that hadn't directly looked at it was, this is bullshit.

[03:44:35] Like, it's not possible. Because they truly believe that. It's not possible. Must be just cutting some corners, not doing the, right? I've said for years that the biggest problem with their architecture is the UTXO store. It should not exist. It was a premature optimization by Satoshi. Every single implementation uses it, is based on it. I also said the same thing about the mempool, should not exist. Have you ever heard the quote from Elon Musk? Biggest problem with engineers is always optimizing things that shouldn't exist. That's a great example.

[03:45:10] So by not having a UTXO store, we do not have to sequentially validate every single block. Last week, I was able to achieve finally parallelism by block for most of what I call the confirmation phase, which is determining whether a previous output is previously confirmed and whether it has been previously confirmed spent. Those are what we call, that's the confirmation phase. So we split, in order to achieve this, we split the process, the whole process of getting synced up into downloading, validating, which has nothing to do with order.

[03:45:54] Just get the previous outputs and validate, right? And confirming, which is determining that everything's happened in the right order. And I believed for some time that that last phase was not going to be very parallelizable because it depends on a query that runs across the entire chain to determine whether the order's right. There's no UTXO store. It just queries the chain. But the validation in the middle can be parallelized entirely. I can run every single block at the same time across the chain. I have 64 cores, so I can do 64 at a time.

[03:46:27] And I was able to move about 90% of the work from that last phase into the parallel phase last week. So that got me from 39, well, sorry, initial block download with assume valid, right? So that's without doing the full validation and the full confirmation. But once we start doing validation and confirmation, we also have this issue. And so I was able to move a lot of that into parallel, which I didn't think I was going to be able to do. So now, basically, we can pull down blocks as fast as the network can provide them.

[03:47:04] And we're network limited. And the fastest I've achieved on this machine is 4.5 hours to download, validate, and confirm the entire chain.

[03:47:18] John Carvalho: When you mention, you know, why can't they do that?

[03:47:22] What's that? Why can't they do that? Who knows? Like,

[03:47:25] Eric Voskuil: These are the experts. These are people for 16 years have been optimizing the same implementation. I haven't even started optimizing. I'm just trying to get a final implementation, right? So there's so... Well, I guess

[03:47:37] John Carvalho: Maybe there's a difference between like an architect and, you know, a developer. It's

[03:47:41] Eric Voskuil: An architectural failing of the design. It was Satoshi's flaw, right? But why can't they see it and fix it? Because it's hugely disruptive. That's the why can't they fix it. It's usually disruptive, and they won't take that work on. So we did, right? But why can't they see it? That's what's really interesting. Like, the people that came and looked at the code, they were looking for the hashing optimization or some little optimization they could actually drop into their code base. There's no dropping any of this into Bitcoin Core.

[03:48:15] This is an entire re-architecture of their own system. I've looked at many ways. How could they do this, right? How could I do this that doesn't require that level of disruption, complete rewrite? And it's just not possible. So that's what I mean. They can't even imagine that it's possible. And then we start having discussions. And after weeks of having these discussions and not really seeing it, the light starts to come on, right? Like, oh. So the only reason I may have this whole discussion and gave this whole monologue about it was because that's the consequence of a monoculture.

[03:48:54] Nobody questions anything, right? It's like, well,

[03:48:57] John Carvalho: I think that's a little bit. It becomes derivative instead of creative, basically.

[03:49:02] Eric Voskuil: Right. All the optimization work is always kind of like lowest level. Nobody's allowed to make any big changes. It's all this low-level stuff, right? So when that came out, the point of me raising this initially was when that started to come out, people started to see that. The response was kind of cynical, like you're not doing it. Some people were actually kind of like, oh, whoa, that's pretty cool. And other people were like, we should probably approve those pull requests based on IBD performance. So there were several outstanding pull requests that had come in where people had been trying to get them through to improve IBD performance.

[03:49:38] And so immediately, there's this flurry of activity, and they approve a bunch of these pull requests, and an intermediate release goes out. And some people are saying, well, you haven't got the latest release. I'm like, look, I took the release, right? And I tuned it the way you said to make it go fastest on my machine. And this is what I got. They said, well, there's a new release. So you got

[03:49:56] John Carvalho: Immediate healthy competition.

[03:49:58] Eric Voskuil: Right. That's the point, like immediately. They're like, oh, my god, it is possible to go faster? Well, we should probably do this stuff. But it turns out that those, again, were, it was like, these were trade-offs. And this is why they were not approving them. It was like, increase the amount of memory available to signature caching, or I don't know which cache it is. I think it's the UTXO cache. So they had put a hard cap on the size of the UTXO cache, and it didn't matter how high I put it in config, it wouldn't go above that.

[03:50:29] It would just chop it off. So they removed that limit, or they made it much bigger, and that was supposed to make it go much faster, people saying, well, I was able to do better. So I did it again. It was, you know, actually, one of our guys did it. One of the guys that came over was Cynical, who was not really a core guy. He was kind of a Luke guy. And he ran. He was like, oh, you know, so it did improve it. But what it did was it shifted almost the full amount of the benefit into shutdown time, because the time to unwind the UTXO store cache was significantly larger.

[03:51:00] And that's why they had capped it in the first place, no doubt, right? It was like 15 minutes to shut down, or even longer. I've seen, even without that, I've seen on my machine very significant shutdown time. Now, the worst shutdown time I've seen in any recent implementation of our stuff is like a minute, right? And we use every single bit of memory available on the computer. We will use 100% of the memory available, and it still shuts down in less than a minute, usually like 10 to 20 seconds.

[03:51:31] So OK, so they couldn't really, they know that they're, you know, these were out there, but they weren't really doing them because they weren't going to provide the advantage. But then somebody, some competition comes along and shows, hey, I can go, I can do this in 37 minutes, and it takes you guys 14 hours. Well, we better like trim a couple minutes off the run. And that's it. So the damage that I'm seeing is because of that lack of ability to think critically about their own implementation, what's happened is performance work, this is just on software scaling, right?

[03:52:07] This has nothing to do with Bitcoin scaling. It's a software scale. The performance work has been driven towards assume this and assume that, right? We've got assume valid, which we implement, same security model, very different implementation as Bitcoin Core. But then there's assume UTXO, which just came, so we're just going to like package up the UTXO set, put it up on some website, and sign it, and you trust me, boom, you download it, you're ready to go, right? So why do we even have Bitcoin at all at that point?

[03:52:36] And then there's this Utreexo stuff coming, which is people have been led to believe that that's kind of a optimization for validation. It is not, not in any way. I actually implemented a significant portion of it recently to see if I could optimize the UTXO, use a Utreexo accumulator to optimize that stage I was talking about. And it's slower in their implementation, like the Utreexo node, and it was much slower from what I saw. It was not going to be an optimization because it still requires a total ordering, even if you can do them in parallel and roll them up, that still produces a total ordering.

[03:53:15] So what's happening is that I've seen, the writing is on the wall. That's becoming another assume scenario, where as long as you're willing to accept this assumption, you can take my proof that this is valid. The only way you would know whether it's valid is if you validated the full chain. Now it's actually slower. So what's happening is because of this lack of ability to improve the software, make it scalable, two things. One is the software itself is becoming more and more dependent on trust assumptions. And two, because of that, there's more and more pushback on things that affect consensus from guys like Luke, for example, who wants to shrink the block size because it can't get synced in time or get fast enough and it's going to keep getting worse.

[03:54:03] And there's other aspects of consensus that have even come to pass in the past, but I think will continue to happen that are driven by poor implementation. And that's driven by the singularity of the community around this one implementation. So I always knew that this was never going to go anywhere until we could ship it and show it actually doing it because nobody believes it. And I was through the math. And if you look at the time it takes to download the amount of data on the wire, the wire size of all blocks, the theoretical limit on my 2.3 gigabit per second network is 34 minutes.

[03:54:45] So I did nothing else except download a single file that had all the blocks in it and put it on my machine. Nothing else. It would take 34 minutes. And I've done it in 37 minutes with a significant amount of validation, building a high level of indexing, and all the other network IO that has to happen in order to pull down the chain, address exchange, et cetera, et cetera. So it's curious why anybody would think it's impossible to do it in 37 minutes when the theoretical limit is 34 minutes.

[03:55:18] But when you're at like 10 to 15 hours to 20 hours depending on the platform, there's something really wrong. And I've graphed this. We have this linear graph like this for validation. And theirs is going like this. It's going vertical. It's not scalable. So as we add more to the chain, the time it takes to process each block is increasing. It's not just a constant rate of increase.

[03:55:43] John Carvalho: That's what we do. So are we going to halt sometime

[03:55:44] Eric Voskuil: Soon? We'll halt. Eventually. Bitcoind will halt. It will cease to be functional. And that's one of the reasons why we're doing what we're doing. They will either re-implement and just basically do what we've done, or they will cease to function. The hardware, it's growing faster than the hardware can keep up the time.

[03:56:05] John Carvalho: I want to know more about, you mentioned earlier optimizing things that shouldn't exist. You mentioned the mempool. Can you describe to me what the better design for how they handle the mempool is? Is it just keeping all transactions arbitrarily on your own or what?

[03:56:20] Eric Voskuil: Yeah, basically. I will do that, but I'm not a mirror. So I need to take a restroom break and I'll be right back. Time out.

[03:56:31] Vlad Costea: It's all good. I can mention some sponsors, which I haven't. I'm

[03:56:38] John Carvalho: Still here. I'm just going to shut off my camera so I can walk around.

[03:56:40] Vlad Costea: Okay. So first of all, thank you guys for being here. I see that we got almost 1,700 views up to this point. We are about four hours in and we are basically halfway in our way to break the record. And I got to tell you about SideShift. Earlier in this interview, so within the first hour, you could hear us talk about tokens and Tether and whatever. And I've also mentioned that Kanye West might be launching some sort of meme coin. If you got any of that crap and you want to swap it for Bitcoin, which according to Eric Voskuil can be BCH or LTC or whatever, you go to SideShift and you can swap your USDT or Kanye West coin coins or whatever for some money that actually makes sense and you can use it for something that you might find useful.

[03:57:44] So check out SideShift.ai. There's no registration required as far as I know. They have pretty low fees and good liquidity. And also have to mention Bitcoin.com news and John can roast me for this one. Say that I sold out or something. But today I read some very useful news there and I think they finally learned the difference between BTC and BCH. And more than that, they have some very good journalistic pieces like Russia's Supreme Court moves to classify crypto as property, which seems to be big news.

[03:58:20] And also ECB expands digital asset settlement, a major shift in European finance. I usually look for this geopolitical coverage that they're doing and is pretty useful. They do good journalism. And unfortunately, I don't see too much of this on other Bitcoin websites because they seem to be more ideological or dogmatic and don't report some of the events that happen around the world. But I like what Bitcoin.com are doing with their news section. So check that out. Get your news from Bitcoin.com. And since I seem to have some extra time, I have to tell you about two possible versions of Bitcoin, two possible versions of the future of Bitcoin, which includes side chains and also ZK roll ups.

[03:59:12] And I suppose these two can be topics for debate for the rest of our interview. On one hand, we have LayerTwo Labs building their drivechains and drivechains are miner enforced side chains, which means on one hand that the miners are going to be in control of the funds where the majority of the hash rate. On the other hand, it also means that the miners are going to expand their revenue from transaction fees. So it's a solution to this Satoshi Nakamoto gamble, because if anything, the biggest gamble is this supply shock with the diminishing block rewards.

[03:59:53] There is no guarantee that the fees are one day going to replace the subsidy that we get from block rewards. So one way to solve this is with drivechains. And it's really interesting. I'm going to interview Paul Sztorc on Monday. I think he wants to talk about some hot topics going on right now. So stay tuned for that one. And thank you LayerTwo Labs for sponsoring the show. And more than this, it's not just an idea. It's software. So John, if you are curious to see what Paul Sztorc did with his drivechains, you can go to layer2labs.com/download.

[04:00:30] And that's where he has the software for pretty much all the side chains that he designed. You can try them on the Bitcoin testnet. I am not curious. Something else that can be a feature of Bitcoin is called Citrea and they're trying to build a ZK rollup. They claim to have been the first ZK rollup that was verified on Bitcoin. And what's interesting about it is that they try to be sort of like, what's the name of it, an L2 on, I think it's called Optimism on Ethereum.

[04:01:03] They try to bring an extra financial layer where you can use your Bitcoin to put it as collateral to borrow money against it and basically do whatever BlockFi and Celsius were doing, but not with a company, but with a protocol and smart contracts and something that you can actually audit and check the rules and make sure that it's honest and it does what it says it does. So check out Citrea. They are building right now and they have a bunch of wallets. They're on the Bitcoin signet, if I'm not mistaken.

[04:01:36] They haven't launched their testnet version. And it's Citrea.xyz. And I'm actually curious, what do you guys think about drivechains? I know what you think, John, because you said it at Baltic Honeybadger on the stage. And also about the ZK rollup protocols that are emerging. And they seem to be pretty popular and seem to be turning BTC into some sort of data availability layer for Ethereum applications.

[04:02:09] John Carvalho: I don't know too much about Citrea. I'll say it sounds like bullshit to me, but I think that most of the proposals that people make with ZK rollups are just imported shitcoinery that are not really going to amount to much. If there are constructions that are useful, fine. I'm not an expert in it. But I haven't seen anybody make any sort of mentionable breakthroughs in other chains or do anything that actually sounds like it would be a sound layer design using these things or anything like that.

[04:02:47] I could be wrong. I don't know enough about it. I'm speaking somewhere ignorantly, but these things tend to be engineers fidgeting around with toys and no real utility to end users. I also want to mention, to rewind a little bit, you said I would give you shit for Bitcoin.com. The first time you said it earlier in the show, I thought you said Bitcoin Magazine, which I was going to give you more shit for. Oh. Because I was like, wait, man, you're advertising Bitcoin Magazine? I'm so surprised.

[04:03:20] Vlad Costea: No, it's the Bitcoin.com news section, which is pretty good, honestly.

[04:03:25] John Carvalho: Yeah, I haven't looked at it in a long time, but I'm not going to give you shit either way because, I don't know, you have to make money, you need sponsors, whatever. Those show scams. You should be fine.

[04:03:37] Yeah, do what you got to do.

[04:03:38] Vlad Costea: What I want to say about these ZK roll-ups is that what they tell their investors is that they're trying to tap into the liquidity that's on Ethereum as WBTC. There's wrapped Bitcoin, and I think there's 130,000 Bitcoins that are locked on Ethereum right now. And they want to bring some of that liquidity to Bitcoin with some of these layers. And they think that if there was the option for some of these people to have the same functionality with better security, then they're going to migrate from WBTC on Ethereum, which is sort of custodial with BitGo, to something which is more trust minimized.

[04:04:22] John Carvalho: I'm skeptical it's going to be much better, if better at all, and that the liquidity would move only for that reason. The liquidity is on Ethereum for other reasons as well. So you have to isolate all of those things. And as far as the drivechains that you brought up, yes, if people want my opinions, they can go look them up in other stage presentations and such too. But I think that bringing it to this conversation, earlier we were talking about how blockchains compete and alternative monies compete.

[04:04:56] I think that drivechains are separate monies, regardless of whether you have the promise of miners backing them with Bitcoin. And thus you're going to have really strange outcomes on how that may affect how miners view Bitcoin and what the security model of Bitcoin is. It could affect the security model of Bitcoin itself. Like, for example, what happens if a side chain is more popular than on-chain? If there's an overweight, what happens if the miners do misbehave? How might that affect the overall Bitcoin price? Things like this.

[04:05:34] I don't see any utility there. I think I'd rather use an altcoin than a drivechain because then I don't have to change Bitcoin to do it.

[04:05:46] Vlad Costea: Eric, do you have any opinions on drivechains or ZK rollups?

[04:05:52] Eric Voskuil: Nope. I like Paul, but I don't work on that stuff.

[04:05:56] John Carvalho: So that's for somebody else.

[04:06:00] I used to like Paul until he turned into a total asshole defending drivechains. Once he joined, what is the name of, LayerTwo Labs, once he did that, I think he hooked up with some bad influences of people. And he basically burned our friendship just by being retarded just because he had to promote his drivechain company.

[04:06:20] Vlad Costea: I think you should speak with him in person because on Twitter, he can be very abrasive.

[04:06:31] John Carvalho: He's welcome to apologize to me anytime. I haven't seen him at a conference in a long time, though.

[04:06:39] Vlad Costea: I should get you two on a podcast just for the lulz. I can only imagine. As long as

[04:06:45] John Carvalho: It's not stuck about drivechains. There's nothing else for me to say about it, you know?

[04:06:55] Vlad Costea: Well, this is what we get if we don't scale, you know? We get drivechains, we get covenants, and we get ZK roll-ups.

[04:07:06] John Carvalho: We could just say- We get complexity that also is not scaling.

[04:07:09] Vlad Costea: Okay, let's make it 16 megabytes and use some of the optimizations that we find in libbitcoin and also use Mimblewimble on an extension block to prune some of the transactions. This technology is out there. It's been tested for years. It's not like we are experimenting SegWit when it came out. It was only on litecoin for like a couple of months and then they added it to Bitcoin.

[04:07:37] Mimblewimble extension blocks have been on litecoin for like three years and they've been mostly ignored. I'm not sure if any of you have-

[04:07:46] John Carvalho: Well, it's taboo now to even discuss block size, right? I only discuss it because I want there to be, like, I don't know, I want to be able to discuss things reasonably, whether they're good ideas or bad ideas and be able to talk about why they are good ideas or bad ideas. But with most Bitcoiners, you can't even talk about block size without getting accusations, being insulted, et cetera, nevermind being a protocol dev trying to work on some sort of pull request or design for implementing in Bitcoin in some safe way.

[04:08:18] So I don't know how the hell you're going to- We can't get people to agree to drivechains. I don't think we're going to get people to agree to covenants unless core really wants to show how it's a governance structure. And yeah, Mimblewimble, same thing. I don't know how you're going to convince people to take on these ideas when they're culturally taboo and when working on culturally taboo things keeps you in the outgroup of protocol developers.

[04:08:48] Vlad Costea: Yeah, but at the same time, who dictates what the culture is? Is it Saylor? Is it Blockstream?

[04:08:54] John Carvalho: The maintainers.

[04:08:57] Vlad Costea: So you're defining the culture of a system according to the core maintainers? Because I don't think Ava Chow or Gloria Zhao or whatever have any strong opinions about anything.

[04:09:13] John Carvalho: Well, they're ultimately the one that decides what gets merged. And if you are on the wrong side of whatever cultural system is, you know, however nuanced it may be behind the scenes, I have no idea. But there's some sort of in-group, out-group cultural aspect to working on Bitcoin Core and Bitcoin Core remains the de facto implementation. And so you have this situation.

[04:09:36] Vlad Costea: I think you're right, because Ava Chow said that he or she is not going to merge anything controversial ever. So as a maintainer, they're going to...

[04:09:47] John Carvalho: Somewhat reasonable. I mean, it's totally reasonable if you think about that. Users have no participation in changes to Bitcoin, and it's just something totally engineer-driven. Yeah, well, put into Bitcoin Core, sorry.

[04:10:04] Vlad Costea: I mean, that sounds like what Monero is doing, right? They have this agreement that they have a common goal and they trust their developers that they're going to achieve it if they trust these guys.

[04:10:19] John Carvalho: Yeah, like Monero does something like fork intentionally every six months, even if they don't have a fork to make that.

[04:10:24] Vlad Costea: They stopped that. They stopped that?

[04:10:27] Okay, yeah. They used to do it. Now they stopped, but they're going to implement something that's called full chain membership proofs. And that one is sort of a big deal because right now they have the decoy system with 16 decoys or something. And one of them is the real transaction. But once they do full chain membership proofs, you're going to have an anonymity set consisting of the entire chain, which is what Zcash is doing.

[04:10:56] Okay.

[04:11:00] But we can't. It's exciting. But once again, it's taboo to talk about this.

[04:11:06] John Carvalho: Yeah, I mean, well, it could be exciting, you know, if you hold Monero, and if you use Monero. But I don't know how practical it is to bring those things over to Bitcoin and what the trade offs and implications would be either. There's always so many nuances with all these things that ultimately, it's just easier to discuss that engineer driven change is not what Bitcoin is meant to be.

[04:11:32] Vlad Costea: Okay, let me tell you something which I've learned from listening to Roger Ver interview very recently. He said he's super bullish on BTC right now. Because there is something that's called confidential layer that can tokenize Bitcoin on another network that's called Zano. And you're going to transact BTC on Zano, just like you transact WBTC on Ethereum, but with very good privacy and low fees. So basically, he's bullish on BTC, the token, because, of course, Bitcoin, the network does not provide this functionality with confidential transactions and low fees.

[04:12:12] John Carvalho: How do you not see that he's bullish about all this just because he wants to shill Zano?

[04:12:17] Vlad Costea: Most likely, yes. But at the same time, Amir Taaki is building DarkFi, which does the same thing. The difference between Zano and DarkFi is that DarkFi is using Halo 2 Zcash cryptography and Zano is using ring signatures from Monero.

[04:12:33] John Carvalho: But DarkFi is a coin?

[04:12:36] Vlad Costea: Of course.

[04:12:37] John Carvalho: I didn't follow that. I didn't know. [unclear: Amir is not allowed to talk about this.] I thought it was like a whole vision. And he has like this, this no identity chat software and some wallet. I never knew.

[04:12:49] Vlad Costea: Of course, he's gonna have a token. I mean, he has investors. There's someone that he must please at the end of the day.

[04:12:56] John Carvalho: I haven't followed this stuff. I don't know.

[04:12:59] Vlad Costea: He's not allowed to talk about it. There are some lawyers that handle everything. But there's gonna be a token.

[04:13:12] Eric Voskuil: I have the popcorn now.

[04:13:17] Vlad Costea: But this can be transacted on some other network because we did not scale. We did not make it fungible.

[04:13:28] John Carvalho: Nothing's fungible.

[04:13:33] Vlad Costea: I'm not so sure about that. Like you can melt gold and make it look like any other piece of gold.

[04:13:41] John Carvalho: Well, you could this gets really kind of a bit. I don't know if it's philosophical what the word is, but the properties of physics just force every literal thing to be unique because everything has to have a unique position in reality. So everything is closer or further to something else than something else's.

[04:14:04] Vlad Costea: OK, but this is not about physics. Physics is just about being able to assess whether or not two pieces of metal or two dollar bills or something are identical.

[04:14:19] John Carvalho: Well, no, whether they're able to be substituted is what fungibility is. Right. And so, for example, is a dollar bill in Africa fungible with a dollar bill in Canada? Not really. Right.

[04:14:39] Vlad Costea: OK, so there's

[04:14:42] John Carvalho: A different expense to getting it out of Canada, to getting it into Canada. There's going to be subjective value to the person holding it. There's like fungibility is not really a useful thing. It's just, I don't know. Maybe you just better talk about supply and demand or, I don't know, fungibility. What you mean is what you actually mean is the ability to transact without censorship based off of the source of your money. Right.

[04:15:09] Eric Voskuil: I tend to look at it from the Bitcoin perspective in terms of taint. Right. If a coin can be tainted, it's it's it's not fungible with a coin that is untainted, that where nobody has the knowledge of where it's been,

[04:15:24] John Carvalho: Who owns it. Right.

[04:15:25] But every coin has some sort of metadata associated with it. Not that much on chain, but a little bit. So thus, every chain has a unique history. I mean, every coin has a unique history, etc. Like Bitcoin tracks the infungibility of the UTXOs. That's what it does.

[04:15:47] Vlad Costea: That's why we should start mining. Seriously.

[04:15:54] John Carvalho: Start mining? I mean, I think it's OK. I think that people think about privacy the wrong way most of the time. Privacy is just metadata. Data that you generate and managing your privacy is managing witnesses. And if you take that fundamental dynamic and apply it to moments where you're trying to be private and build tools that allow people as much control as they could possibly have to control witnesses, then you're building privacy tools. But most people don't take all the steps required to maximize their creation of metadata. Basically, when you act on a network, there's always going to be at least one witness.

[04:16:32] And so they leak all over the place and then they pretend and they larp, they play games that they're, you know, mixing their coins and these kinds of things, while meanwhile, they just have no fungibility at all. And it's just kind of they've they've maybe made it so their landlord can't tell, you know, which UTXO they, you know, how much Bitcoin they had in that UTXO where it came from. But they haven't actually, like, overcome any sort of surveillance of anything of note. They certainly haven't overcome state surveillance, which can look at the actual Internet network itself and look at behavior and make correlations.

[04:17:11] So it's like a lot of the privacy conversation just feels so hypothetical and larpy. Like, just it's a performance a lot of the time. Because the people that actually need it, they're playing totally different games. The people actually hunting people using these kinds of methods, blockchain analysis. Network analysis. This is a totally different game that people are playing, and most people aren't even remotely qualified to overcome it. And so if you want to have a practical approach to managing privacy in your life or designing tools and software to improve privacy, you've just got to be doing that basic function of giving people more ways to control the witnesses of their data.

[04:17:52] Now, of course, you could say, if I can't associate anything with your UTXO or with your coins, then then I've achieved fungibility and thus you're not creating metadata. But then you won't be able to do other things with that coin. You won't know who is allowed to spend it or, you know, what happened to it in the past or whether it's been double spent. There's all kinds of other things you need to have the uniqueness tracked that make it useful and actual possible to be used. So it's like this, I know I'm speaking abstractly, but I think that this is how I reason about these ideas and when I think about privacy and why I think of it as, okay, if we're talking about the government, I don't care.

[04:18:37] Like, if you're a target of the government, you've got to be some kind of super hacker. And you have probably have to have done something really, really scary, really, really risky to even be having that conversation. And Bitcoin is probably not what you want to be using in that situation. Probably not Monero either. And so you also have things like using privacy dedicated things makes you suspicious to people who are watching out for people that are doing bad things. And so you have another trade off as well as where now, are you are you hiding in a crowd?

[04:19:12] Or are you hiding amongst a bunch of thieves? And which one is actually going to serve you? You know,

[04:19:21] Vlad Costea: Yeah, but in the case of Bitcoin, I thought about this a lot, because people tell me, okay, Vlad, so I withdraw the coins from an exchange, and then send them to my hardware wallet into separate transactions. How can you prove that the address belongs to me, and I didn't pay someone else. So they appeal to deniability. And they say that by virtue of

[04:19:42] John Carvalho: You have plausible, I have deniability in one hop, you don't need to mix at all. If you are plausible, anybody say I sent the coin to Joe, who's Joe, I don't know, some guy, you know, I met him at a bar.

[04:19:55] Vlad Costea: But it's temporary, because you're only going to have this deniability for as long as you don't sell. And by the time you sell, you're gonna have to KYC most likely.

[04:20:06] John Carvalho: But it's an illusion that you can separate that history and sell in the future. That's the illusion is that that that's what Bitcoin does is it tracks all over the connections to where that Bitcoin came from, but that's exactly what I'm the best you can do is create the Yeah, yeah, the best the best you can do is hope that the you can hide in a set of similar transactions. But then they'll just track the whole set until they find you. So it's so easy. I just think that Bitcoin mixing is so fake.

[04:20:39] And does nothing.

[04:20:44] Vlad Costea: Once again, it depends on who's analyzing. If you're paying your rent, as you say,

[04:20:50] John Carvalho: Right, if you're hiding from your landlord, then yes, you can amateur surveillance, you can very easily you could do this by just sending your own Bitcoin transactions to yourself at random once a day. And then you're all your UTXOs get, you know, mixed with new addresses and and make them as small as is practical. So you are ideally sending as close to a whole UTXO when you are sending them. And then you're managing your privacy, like in Bitcoin.

[04:21:19] Vlad Costea: Anyway, people doing crime with Bitcoin who have a budget for this, they just buy from a mining pool. So there's no taint.

[04:21:29] John Carvalho: That's what that's what we say. But I don't think that's actually happening very much. I don't think miners are selling to the I don't I know of no premium for freshly mined coins, or a marketplace for freshly mined coins. But that just because I don't know about it doesn't mean anything.

[04:21:46] Eric Voskuil: Sometimes, if you're serious, you just mine yourself.

[04:21:48] John Carvalho: Yeah, although mining yourself requires a certain a stature of, of company to be able to reliably mine any Bitcoin at all, you end up registering as a company, you end up making yourself sensible and adding tracing and metadata outside of the Bitcoin.

[04:22:12] Eric Voskuil: Registering as a company, the criminal element who needs private money is registering as company.

[04:22:17] John Carvalho: Well, how are they going to scale up the electricity and get all of the resources they need to be able to mine?

[04:22:22] Eric Voskuil: Maybe their cousin runs the hydro plant in central China.

[04:22:28] John Carvalho: Yeah, I mean, we could talk about obscure possibilities. But as far as actually applying this as a method doesn't seem like anything. It seems like something only the state could do.

[04:22:43] Vlad Costea: And just the thing that this started from a silly or maybe naive assumption of one CPU one vote. And Satoshi actually sent an email to Laszlo, who was possibly the first GPU miner and told him, you know, can you please stop, like, let new users get 50 bitcoins with their clients mining with their CPUs. And then we got to this point.

[04:23:09] John Carvalho: Why didn't he just fork it and slow down the release schedule? If that was his concern?

[04:23:15] Vlad Costea: I don't know.

[04:23:17] Eric Voskuil: Well, the difficulty adjustment slows down the release schedule.

[04:23:22] John Carvalho: No, I mean, in other words, like have it spread more out over like numbers, less difficulty changes.

[04:23:29] Eric Voskuil: But if somebody's got 99% of the hash power, how do you spread it out?

[04:23:35] John Carvalho: Well, the first epoch is 50. And the next is 25. I guess you make it 50, then 40, then 30, or some other arbitrary slower output.

[04:23:49] Eric Voskuil: Then you're slowing the block rate, which means you have to increase the difficulty. So

[04:23:52] John Carvalho: You're slowing the reward rate, not the block rate. By the way,

[04:23:57] Eric Voskuil: It's arbitrary. I mean, Satoshi even said that he understood that.

[04:24:05] John Carvalho: But look at this way, there was a certain amount of hash power in the first year that was put towards Bitcoin. If the block reward was 50, it would be a certain amount of Bitcoin created. If it was 20, it would be 25, it would be half as much Bitcoin created in the same amount of time.

[04:24:20] Eric Voskuil: Right. But what matters is the percentage over that time of the newly created coin going to that one person.

[04:24:28] John Carvalho: Oh, so in other words, even though they had only gotten 25 Bitcoin instead of 50, they would still have the same proportion. They got 99%

[04:24:36] Eric Voskuil: More than everybody else.

[04:24:38] John Carvalho: Yeah, yeah. Yeah. Because nobody else gets the advantage over him. That's the problem.

[04:24:44] Eric Voskuil: And that'll be perpetual. So until other people build up their hash rate. That's the way it works. I mean, you know, not really much you can do, except maybe ask a guy to stop.

[04:24:59] Hey, chill out, dude.

[04:25:04] John Carvalho: What about you, Eric? What do you think about privacy topics in Bitcoin and blockchains?

[04:25:09] Eric Voskuil: I mean, I think privacy is one of the most important aspects of core development in improving privacy. Because the value proposition accrues to Bitcoin when you're doing things that are not allowed.

[04:25:25] John Carvalho: Otherwise, what does that look like, though? In other words, yeah, having better privacy is something nobody would argue with. But how? Well, reduce tainting.

[04:25:37] Eric Voskuil: That's, that's the objective. But I mean, how I haven't, I have not been a big proponent of most of the things that I've seen. Like, for example, mixing, I've never, you know, I, I just caution people that, you know, don't put too much faith in these in the security of these things. I don't think it's always as easy as you imply. But I also don't think that there's sufficient security against real threats in mixing. And I mean, ultimately, what you described as the anonymity set, right, is that's the basis of privacy.

[04:26:15] But it comes right down to it is creating an large enough anonymity set and being in it, essentially what mixing is, but I haven't seen anything that that that looks sufficient for real threats. And what was the other aspect you asked you asked about?

[04:26:39] Wasn't just mixing,

[04:26:42] John Carvalho: We covered Mimblewimble, fungibility, mixing, leaking metadata on a network to witnesses.

[04:26:53] Eric Voskuil: Sorry, I had another thought that I lost it having to do with privacy that wasn't related to mixing.

[04:27:02] No, no, I'll think of it in a minute.

[04:27:07] Vlad Costea: In the white paper, there's this description of Bitcoin, there's chapter 10, that talks about privacy. And Satoshi assumes that users are going to generate a new address. I think it's described as a public key for every transaction. But for multi input ones, for multi input transactions, there's always going to be some linking when you're batching UTXOs or whatever. So he was correct. And he described the limitations. He also wanted to pursue zero knowledge proofs. And there are not too many libraries at the time for this. There are some posts on Bitcoin talk.

[04:27:53] And then in 2013, we had two papers, one of them was called Zerocoin, and the other one was called Zerocash. And they were trying to bring zero knowledge proofs into Bitcoin as a soft fork. There was no consensus for this. If you look at the original thread by Greg Maxwell about coin joins, he actually talks about Zerocoin and Zerocash and says that they're too avant garde or maybe not battle tested enough for Bitcoin. But maybe we can get something similar with coin joins and proposes that someone builds this CoinJoin wallet.

[04:28:31] So we had these proposals. We did see how they evolved over time. I think right now Zcash is pretty advanced. But where I'm heading with this is that Amir Taaki came up with the first implementation of a CoinJoin wallet. And it was called Dark Wallet. And the reason why it did not get the bounty from Greg Maxwell was that there was this John Dillon character who was corresponding in private or unless they were the same person with Peter Todd. And basically, what John Dillon did was say, so he was basically the Michael Saylor of 2013.

[04:29:08] He said, if I send this amount of Bitcoin to the bounty address, then I'm going to have a word to say in how this bounty is being distributed. And then the private conversation with Peter Todd, John Dillon seems very concerned with the fact that Amir used libbitcoin for Dark Wallet. And he seems to have this line of argumentation that there should only be one client. And it's dangerous for libbitcoin to get traction.

[04:29:42] John Carvalho: So there is anyone on core not have that?

[04:29:45] Eric Voskuil: Who is this guy again?

[04:29:48] Vlad Costea: John Dillon. Sock puppet.

[04:29:51] John Carvalho: Are you haven't heard the John Dillon? I don't know. It's goes back.

[04:29:57] Eric Voskuil: Referred to it a while back, but I don't I didn't know it.

[04:30:02] Vlad Costea: Are you sure you're friends with Amir? Because he talks about it all the time. It's like,

[04:30:06] Eric Voskuil: You know, you think I listened to your Amir podcast that go on for seven hours.

[04:30:12] I see I see Amir maybe once a year. And, you know, we don't talk about this stuff.

[04:30:20] Vlad Costea: He finds a lot of frustration in the fact that he did not get that bounty and that project was killed pretty early on. He never had a chance. Dark Wallet. Yeah.

[04:30:32] Eric Voskuil: Killed? I don't know.

[04:30:34] I don't I don't know. I didn't I don't know the story of that bounty. I mean, I was directly involved with libbitcoin at the time. He was working on Dark Wallet, but I never worked on Dark Wallet. And some of the stuff he was doing was pushed back in to our code base. But by that time, I was I was managing it. And, you know, I went down to Cody's apartment in Austin for the Dark Wallet release announcement, which, you know, obviously a bit of a pre release announcement.

[04:30:59] But that's where that's where I think I met Peter Todd for the first time and Andy Greenberg and

[04:31:04] Vlad Costea: Vitalik, I guess he was also there.

[04:31:07] Eric Voskuil: No, I wasn't there. But phantomcircuit. I can't remember his name right now. He was the one that actually laid down the first line of code for libbitcoin. Amir kind of found him online when he wanted to start working on libbitcoin, and they did it together for a while. I spent a couple nights at his place in Austin. He was a big miner. I can't remember his name. But he had about 5% of the hash power in the network in like in Texas. He eventually went to work for Blockstream.

[04:31:39] I don't know what he's doing now. But that was kind of it was pretty early. I mean, Dark Wallet never quite got finished. And libbitcoin never quite got finished. I mean, there were releases, but, you know, I've been working on it. I've been working on it for about 10 years, 11 years. We did a couple releases, but I've never considered it done. There were significant limitations in like the last release, v3 release, which I worked on and prototyped for a couple years and set it aside and then came back once I figured it out.

[04:32:12] I figured out how to resolve the issues that we were dealing with, started over, and it's been good since then. But a lot of work. And so Amir is, I think, really good at getting things started. And I think, over time, he's like, what he's been doing with DarkFi? I don't follow it. I've never looked at any code. I haven't been involved in any way. But just from following his trajectory, it seems like he, especially after raising money, right, he's gotten better at the finishing aspect or completing, right, like shipping, right?

[04:32:48] Because in my prior life, I shipped software that Fortune 500 companies ran, right? We sold to Pepsi and whoever, big companies. And then we sold to Microsoft. And I was a principal architect there. And then, you know, we also created the company called BeyondTrust now, which I'm not involved with anymore. But it keeps getting bigger. And it hit the news in a big way, like last year, when there was that big government hack in the US, Treasury Department hack. They were involved in that. That was a company I created.

[04:33:27] So my perspective is, I understand what it takes to kind of ship a finished product and make it maintainable. And that's a lot different than getting something started. And my perspective, I mean, Amir's, the decisions he made to create libbitcoin and the architectural and design things that he came up with, which I was involved with as they were evolving the first couple releases before I kind of took over, were excellent. He had excellent insights and just hadn't, you know, his kind of, had this very ad hoc approach to releasing and maintaining.

[04:34:09] It's like, just get the open source out there. People maintain it. And that's, you know, there's a need for that. It got to the point where, and this applies to Dark Wallet, too. And DarkMarket, right? That became OpenBazaar. That was like a one-day project that he did with a couple of guys from Airbitz, which became Edge Wallet, right? All Paul Puey's guys. They were working on libbitcoin as well. And that was based on libbitcoin. And then there was DarkLeaks. There was DarkMarket, DarkLeaks, Dark Wallet, libbitcoin, and now DarkFi.

[04:34:43] None of these things were mature products. Even libbitcoin was not mature, even with releases. It was not really a maintainable project yet. But I have worked on it for a very long time. And there's very little deviation from the core principles that is the architectural decisions he made, even at this point. His code is significantly different. But so I don't know. I think he's getting better at getting kind of production quality release maintainable software. Because there's so much. We didn't even have continuous integration when I joined.

[04:35:25] We didn't have anything executing tests. We had ad hoc generated installer scripts, things like that, which would always kind of drift and fail. And so we spent a ton of time on code generation and CI and testing cross-platform. Well, that's been a major part of it. So Dark Wallet, from what I saw, it was kind of similar to libbitcoin. It got to the point where it sort of worked. I never used it myself. But I never got the feeling like it was done. And maybe the collapse of some pending donation led to that.

[04:36:05] I don't know. I wasn't involved in that. I know there were people that claimed that him and his team ran off with the Kickstarter money or whatever it was that they, I think it was like 50 or 60K USD that they brought in. I'm like, you got to be kidding me. I bring a decent developer on to work on libbitcoin. And it's like 200 a year. They had like several guys working on this thing. And they only raised about 50K. So I don't know what kind of mindset people have in terms of professional software development. And now,

[04:36:37] Vlad Costea: Jesus. Well, they raised Bitcoin. And I guess people came many years later being like, well, I sent you 50 Bitcoin, and now they're worth this much.

[04:36:47] Eric Voskuil: The total value of all the Bitcoin they raised through the Kickstarter thing, I think, was about 50 grand at the time. And it got spent, as far as I know. I didn't receive any of it. And what else? What else were they living on? So it's not a lot of money. Nowadays, you try to bring somebody on that has some skill, a professional developer, who even if he wants to kind of take a hit so he can work on a project like libbitcoin, I mean, 200K a year was kind of minimum.

[04:37:23] The numbers I've seen recently, I was talking to my old college roommate. He's a senior developer. We were both computer science. And he works for a company. And he's looking around the market. And for senior developer positions now, we're like 350K, unless that's inflation. But OK. And I'm looking at Amir's 50K.

[04:37:41] John Carvalho: I was going to say, a lot of these are American numbers. I should just claim for listening. Well, sure. Yeah.

[04:37:46] Eric Voskuil: But maybe he was raising European dollars at the time. But still, it was 50K. It was maybe like at the time, we got one decent developer who's taken a hit. That's a year, maybe. So

[04:38:00] John Carvalho: I'm not trying to argue 50K is a lot 10 years ago or now.

[04:38:05] Eric Voskuil: I just thought it was hilarious that people thought. They have no concept of what these things cost. You just whip that together. I guess now, this AI could write Dark Wallet in a few minutes. But, you know, libbitcoin has, last time I measured, which was probably like seven years ago, we had a half a million lines of code with 10 repositories, support for all compilers for all platforms, all build systems. And it's a lot. And people expect professional quality products, right? I mean, how much money do you think gets sucked into Bitcoin Core and related Bitcoin Core things, cash donations from whatever, right?

[04:38:55] It's a lot. We hit nothing. We've wasted some here and there, private donors who don't want to be named. But for the most part, I've never taken a nickel to ever do anything with Bitcoin, not speak, not consult. I've only taken travel even for consulting. And so that's the way I like it. It's no strings attached. But that's hard to come by. And there's nobody that can work on libbitcoin that has experience in Bitcoin that's just going to do that forever. Some people have done it for a couple of years.

[04:39:29] But so it's expensive. And we don't get the flow of cash that goes to Bitcoin Core. They get money coming out their ears, from what I can see. And there is a concerted effort to make sure that that goes towards them and not towards others. And when you mention this John Dillon character, is it a real person? Is it a pseudonym? Does anybody know who it is? Because when you mention that, all I can think of is it's one of Maxwell's sock puppets. That's what it sounds like.

[04:39:57] Vlad Costea: Which is funny because in this exchange, so I actually wrote an entire Twitter thread with my takeaways from reading all the emails. I think it took me like one hour to read everything and then make summaries. It took me another one hour. But there was this exchange between Peter Todd and John Dillon, where John Dillon was saying, you know, people told me that I might be Greg Maxwell.

[04:40:28] I'm just guessing. I had no idea. And Peter Todd said, you know, someone told me that we might be the same person. Yeah,

[04:40:39] Eric Voskuil: I've never known Peter to be much of a sock puppeteer. But Greg was busted more than once, I think. And that was, you know, he didn't have any love for libbitcoin. I butted heads with him a couple times. There was a bit, I don't know, the encryption bit, 151, whatever. There was two of them years ago that got withdrawn and then redone later. I was the only one that critiqued him. It was another one of these things where I'm like, wait a minute, what are you guys doing?

[04:41:09] He was so bent out of shape about me critiquing it. One voice. Out of all of them, one voice. He was really not happy with it. Wrote me a private note about it. And so I never disclosed what he said. But yeah, it was like, how dare you question this is all goodness. Well, what you're doing is you're making a VPN in the P2P protocol. Somebody might take advantage of that. Like, know your customer. Like, if you're going to run an exchange, big miner, you're now required to know your customer.

[04:41:52] Make sure that you have certificates from everybody that connects to your node, or you're taking transactions from money liners. Why would you build that into the protocol? It got withdrawn, but I was the only one that critiqued him. He was pissed.

[04:42:09] Opportunistic encryption. They eventually did the opportunistic encryption, but the previous one, there were two BIPs. I think it was 151, 152. One was a prerequisite to the other, and the other was VPN and whitelisting your peers. And the opportunistic encryption was how they were selling it, but what was being sold was a VPN. And I was strong against both of them. Opportunistic encryption in a peer-to-peer system where all of the data is validated anyway is pointless. It's public validated data. And so the argument was that, well, people could submit transactions to the network, and other people are going to see where they originate.

[04:42:58] I'm like, well, how does opportunistic encryption change that? The threat just connects to everybody and sees where it comes from. The threat can encrypt with you, can connect to you, and that's much easier than monitoring the wires. So I never quite got it. It didn't make any sense. And this is another case of, from an engineering standpoint, it might have just been a case of focusing on the details and missing the big picture. Encryption is always good, right?

[04:43:33] John Carvalho: Do you have any thoughts on the, I forgot what the whole name of it is, but the Great Consensus Cleanup or whatever they're calling it? Oh, yeah,

[04:43:40] Eric Voskuil: Yeah. Let's set that aside for a second. This was one thing I had forgotten earlier. Dandelion, right? Do you remember talking about privacy and mixing? Well, this is the other, this is another...

[04:43:51] Vlad Costea: They have it on Monero. What? They have it on Monero.

[04:43:54] Eric Voskuil: Right. So Dandelion was, I don't think it got adopted, and I think for good reason. It was another one of these things where you take weak, very weak privacy, and you sell it as something that people then use to their detriment. And that kind of falls into the same category, I think, is a lot of the mixing. And the idea was, in my opinion, if you want to post a transaction to the P2P network or to any network so it can get to a miner, except you should use the best technology available, which is an anonymizer, I2P, Tor, or something like that.

[04:44:36] That's what they do. Bitcoin's not in competition with those, not going to come anywhere close. Maybe they don't work great, but they're the best available, either that or mine it yourself. But it's the same basic issue. So the same holds for mining and for transacting. You submit something new to the network, you are exposing yourself. And so what you want to do is find a public node or server or whatever that's willing to accept traffic and connect to it using an anonymizer and post to it so nobody knows where it came from.

[04:45:08] And at that point, you're trusting the state of the art in terms of anonymizing technology. Relying on something like Dandelion to obscure where you're coming from or opportunistic encryption, which doesn't hide anything, doesn't even hide the fact that you're using Bitcoin, to me, it was pointless. So yeah, that was my take on it. So same thing with BIP-37, which was

[04:45:35] Vlad Costea: You mean 47, the one with stealth addresses?

[04:45:40] Eric Voskuil: No, BIP-37, I think it's 37. It's now largely defunct, a light wallet protocol, superseded by memory so bad.

[04:46:00] What was it? It was Bloom

[04:46:05] John Carvalho: Filters? Your first one is Bloom filtering.

[04:46:08] Eric Voskuil: Right, Bloom filters, superseded by compact filters. I forget about it. It's called Neutrino, compact filters. So we implemented Neutrino. We never implemented BIP-37. Amir was against it. I looked at it. I was against it. We never implemented it. And eventually, it went away. That was one of the things he fought back on with Mike Hearn. And I don't know if Jeff was there, but maybe Gavin. They were pushing this stuff out. And Amir's like, this isn't private. This isn't good design. And now, it's gone. And there's something better, which is great.

[04:46:42] But never implemented that. I never implemented the opportunistic encryption. I don't have any intent to implement the new version of the opportunistic encryption. I never implemented Dandelion. Anything that's a faux security privacy, don't bother. It's not worth doing. It's counterproductive, and it's just burning time and energy.

[04:47:04] Anyway, sorry. So that was just filling in that blank. But what was it that you had asked me?

[04:47:10] John Carvalho: The current soft fork on the docket that seems to be reaching consensus is the great soft fork cleanup, or I forgot if

[04:47:20] Vlad Costea: That's the right title for it. The great script

[04:47:22] John Carvalho: Restoration. There you go.

[04:47:24] Great script restoration. I don't know. Or these two different things. Yeah, consensus cleanup.

[04:47:30] Eric Voskuil: Yeah. So I engaged extensively on one aspect of the consensus cleanup. I'm curious about another aspect, but I just don't want to spend the time on it. Generally, I tend to let, as long as people are making what I see as rational arguments and they're trade-offs, I tend to not get involved. I'm more interested in a good implementation and design and truthful rendering of the trade-offs than I am in what decisions actually get made in the end. I tend to trust the community to make decent decisions.

[04:48:14] They don't always, like, well, there wasn't much of a community actually with BIP 37, but it got better. And I made a comment about the opportunistic encryption thing because the arguments weren't legit. So I challenged the arguments, not the decision to put it in, but the reasons that were being given for putting it in. And if they want to put it in afterwards, because it went in afterwards without the VPN. So that tends to be the case with most. The same thing happened with SegWit. I kind of wish that I had commented on the implementation of SegWit, because I really don't like the serialization that they did, which they probably saw as inconsequential and never even gave it a second thought because different implementation.

[04:48:55] But otherwise, I don't have any issues with it. So when it comes to the cleanup, I looked it over. It was nice of them. The new team is, I think, more open. And I got invited to the private thread on the security issues that they were dealing with. And it requires some time to really get into something like that and make informed comments. And I saw what they were dealing with. I saw the comments and went, OK, well, this guy's probably going to do as good a job as I'm going to.

[04:49:33] I'm going to let it go. I got other things to work on. But every once in a while, there's something that I have worked on extensively. And I see it come across. And I'm like, OK, well, at least I can provide some value here. And it just so happened that I had been working on node sync, right? And some of these things, some aspects get put off till later because they're not that important. One of these aspects was malleation. So, not script malleation, it's a Merkle tree malleation, and two forms of that. And I had been dealing with it to make sure that we were not going to have any issues. And I saw this 64-byte transaction thing came up. And if you go to Delving, you'll find a pretty extensive, detailed, long thread about this. And to me, it was like, OK, invalid. So the proposal is we just take all 64-byte transactions, and we make them invalid in the future. And this was the least controversial of all the proposals. Basically, they kind of said this is a fait accompli.

[04:50:47] Everybody's behind it. Everybody gets all it. It's going to happen. And that was the one where I said, this is bullshit. It was classic. I'm on my own again. Not because I thought I saw any catastrophic fallout from it, but because the arguments in favor of it didn't make any sense. And I was like, look, if we're going to do something like, so if there was no argument for it, and you did it, you've created this weird seam in the middle of all the possible transactions from, I don't know how much the lowest possible is, but 64 is not the lowest.

[04:51:26] So from n to 4 meg or whatever, there's this one little slice that doesn't work. And who knows what that's going to affect in the future? So I figure if you're going to do it, at least do it knowing that you're doing it for no reason. And initially, it was like, I was crazy. I was the crazy one. I'm like, everybody agrees on this. Maxwell and Peter and everybody. Peter Todd, I'm sure, had a look at it. And I'm sure Pieter Wuille. Everybody. Nobody noticed. So again, this is one of these things where if you're part of the monoculture, you tend, one, not to be as critical, and two, not to have seen things from a different perspective.

[04:52:13] I was looking at things from a very different perspective than they were because they look at their own implementation. These are protocol questions. They don't have anything to do with the implementation unless implementation issues become necessary. So there were like four arguments for doing this, and not one of them was valid that were presented. And in the end, I think they're going to do it anyway, after having acknowledged that none of the arguments are valid. But having found another argument that's weak enough that they acknowledge this would never get done unless it was in a roll-up.

[04:52:47] So that's going to probably happen anyway. And the sole remaining argument is that it's slightly cheaper in terms of bandwidth and maybe computation slightly for a SPV wallet to essentially validate the portion of the chain. And the reason for that is that the SPV wallet doesn't have the chain that it validates if they invalidate 64-byte transactions. That's it. In other words, to be specific, the SPV wallet no longer has to download the Coinbase transaction.

[04:53:21] John Carvalho: I can report that people making SPV wallets have no issues with performance as it stands right now.

[04:53:27] Eric Voskuil: I did the math. I actually went through the entire chain using my node, and I measured the size of all the Coinbase transactions and averaged it out. And it came out to, I think it was 100 bytes. So for an average of savings of 100 bytes, which is a nanosecond of bandwidth, where you're not even saving it. You just read it. I guess you hash it. You probably have to hash it. But the idea is that the malleability question gets eliminated if you ensure that the Coinbase transaction starts with a null point, which means the hash is all zeros and the index is all ones, bits.

[04:54:16] And that's a null point. It has to be a null point to be valid. So here's the valid Coinbase hash. And we take the hash of that, and we incorporate it into the Merkle tree hash validation.

[04:54:34] So if you don't do that, somebody could do some 2 to the 24th hashing level difficulty stuff, not easy, but doable, feasible, and produce a fake version of the block for you. OK, so we're going to impose a new rule that says you have to measure the size of every transaction, which you have to do anyway in order to do the block size limit, and throw out any transaction that's 60 bytes. You have to do 64 bytes after a certain point. Presumably, you have to continue to do this in prior blocks so that those SPV wallets don't have to do that one step.

[04:55:14] And then, of course, the servers don't have to provide the Coinbase transaction. And of course, the Coinbase transaction could be big in some cases. But on the average, it's absurdly small. So the way I look at that is they didn't want to give it up because they had already decided they were going to do it. And so this.

[04:55:32] John Carvalho: Since when have any protocol developers cared about apps? They never ever did something because apps needed

[04:55:40] Eric Voskuil: It. Had nothing to do with node security, had nothing to do with consensus, but had nothing to do with anything but implementation. And so there's another aspect of this, too, right? So I probably can't remember all the four or so issues that were raised as reasons to do this. But it was almost like if you throw enough reasons at something, it's like, OK, we're just going to do it, right? But if you take a look at every single one of them carefully, and you go, well, this is not.

[04:56:07] And you find out that all of them are not issues. And then you come on. Then you present another one, which is like, oh, well, yeah. But there's this thing on the wall that has nothing to do with the node that we could make life easier for them. Then you do it anyway. It tells me, like, you just don't want to admit that you fucked it up. And if they do it in the end, is it going to cause any real, you know, no, it's not a big deal.

[04:56:28] But so one of the arguments was if you, and this was a bug in Bitcoin Core that, you know, because of the way they implemented it, had nothing to do with consensus. But they would take a hash of a block. So a block comes, they read a block over the network. And they hash the header, which produces that, you know, the header hash, which is the hash of the block. You're not hashing the transactions. You're only hashing the header. The transactions are committed to the block through the Merkle tree, and the Merkle root is stored in the block, and then you hash that.

[04:57:00] So the hash of the block is just the hash of the first, I don't know what it is, headers like 80 bytes. And then you find out, you know, you're validating the block, and then you find out somewhere along the line that this block is invalid. And so you store the hash of the invalid block. Another block comes along, has the same hash. It turns out it's valid. But you're rejecting it because you stored that hash as always invalid. And the reason this happened, this actually did happen, right, was because the valid block came second.

[04:57:32] The invalid block came first, but was actually just a malleated Merkle root. So it produced the same Merkle root, but it wasn't the same Merkle tree. And so one of my comments was, why are you storing hashes of invalid blocks? That doesn't make any sense. OK, now you probably scratch your head and go, well, it makes sense to me. But they just really never thought about it.

[04:58:03] John Carvalho: What it's worth, I asked that question when you said it in my head.

[04:58:06] Eric Voskuil: It's intuitive, right? But that's not necessarily good. So do you remember, I don't know, you guys might know, about six months or so ago, there was a documentation of a core bug. Some of them have been retroactive, but I think this is actually a new one, where a peer could crash a core node by overflowing the ban list. Do you remember that?

[04:58:43] John Carvalho: I don't remember the time. I remember there had been a couple of bugs in the past year.

[04:58:46] Eric Voskuil: This was written basically by, in other words, there was no guard on the size of the list, so you just overflow the memory. And so in other words, by connecting enough times under different IP addresses that they thought they were banning, so they're banning IP addresses or something, right? And you do something, you get banned. You do something else, you get banned. Well, the assumption in the implementation is that you always show up with the same IP address, but clearly they know you can always, you know, you can mask your IP address.

[04:59:13] So you're connecting under a different identity repeatedly and forever, right, until the ban list gets so big that you crash. I think this was recently a bug that was actually bringing down machines. They fixed it and then announced it, right? And I'm like, well, why would you store a ban list? We explicitly don't do these things because of these problems, right? Because eventually your list gets full. You're starting to run out of memory and you have to make a choice. What do you do? You start throwing out data from the list.

[04:59:41] It's all you can do. There's no other option. So eventually you have to decide that it's arbitrary. You're going to store some, you're going to throw out others. Eventually they're just going to keep doing what they're doing anyway. And you just have this rotating big chunk of memory that's just wasted. So we don't do it. It's not part of our DOS strategy to store bad actors. We drop them and we reconnect other ones quickly and we move on. So what I'm describing is an analogy to the stored hash.

[05:00:10] Why would you store the hash of an invalid block even if it wasn't possible to malleate, right? So their problem was this malleation caused them to not be able to store the hash, right? We want to be able to store the hash so we know that that's an invalid block when we hash the first 80 bytes. And so we're going to invalidate transactions because that makes it possible. And I was successful in showing them that this is not a rational strategy and you shouldn't do this and this should not be a reason for justifying this soft fork. And the reason is because so what they ended up having to do was store the hash as long as they could show the Merkle tree wasn't malleated. If it was malleated, they just wouldn't store the hash, and then they would have the same problem, so they weren't really able to effectively close that hole. And I showed them that the hole is always wide open. So first of all, when you get a bunch of data over the wire, the first 80 bytes might be a header. It could be random data.

[05:01:10] Okay, it looks like a header. Just straight length. The rest of it could be absolute garbage, just nonsense. It could be a terabyte of data. It could be anything, right? It could be some photos. Who knows? And so you get this header in, and you hash it, and then you look at the rest of the block. It comes over as a block message, as a message identifier. And you say, oh, it's not valid. So you take that hash and you put it in the hash list. And then another one comes in, another one, another one.

[05:01:36] There's no limit to the number of those you can produce. Just send different photos with everybody. They'll have the same hash. Well, okay, so you're seeing the same hash over and over again. Okay, now start grinding the nonce, right? I mean, not even grinding, just vary the nonce. Now you can send as many as you want. There's no limit to the number of invalid blocks that you can send to a peer. So they will just, it's just a DOS vector waiting to happen. And I bet you, if I haven't gone looked, but I bet you after this conversation, somebody went back and looked at the code and probably said, ooh, we got to guard against this DOS vector, because they had just had the same failure with their ban list.

[05:02:14] So I was like, okay, that doesn't make sense. And what you really want to do is you want to reject the block as fast as you can, once you know it's invalid, and then just drop the peer. They're sending you an invalid block, just drop them. Don't ban them, and don't store the hash, just drop them. There's no benefit now to the peer doing that to you, except he ties up a little bit of your, you know, ties up one of your ports for a fraction of a second.

[05:02:38] Now, so I think performance-wise, you'll actually be much better not doing all that other stuff, because you have to search the ban list for every block that comes over, right? That's hugely expensive. It's a hash map search. You don't want to do that. When

[05:02:51] John Carvalho: You drop a bad peer, what stops them from just retrying? Nothing.

[05:02:56] Eric Voskuil: And nothing can stop them from retrying. That's my point.

[05:03:00] John Carvalho: But is your point that Bitcoin is easy to DoS?

[05:03:03] Eric Voskuil: No, that doesn't make it easy to DoS, actually, just because somebody can connect to you. You just identify it and drop them quickly. If they're following the protocol, you keep them. If they're breaking the protocol, you drop them. That's it. And, you know, if you don't want anybody connecting inbound, you just don't have any inbound ports. If you have a real DOS problem, you're going to need other infrastructure to solve for that, right? You're going to need a front end on your server, right? And none of these things that they suggested would actually solve the problems that they suggested they solve, which is why they actually do it themselves by enabling these vectors of overflows.

[05:03:44] So then you get to the point where, okay, but we want to be able to identify the fact that it's an invalid block early without having to validate the whole block every time it comes in. I'm like, well, that's reasonable. So what does it actually take? What does it actually take to produce a malleated hash that produces the same header hash, a malleated Merkle tree? What does it cost to produce that? Well, it costs nothing. So if you, in other words, you can add two transactions that are identical to the same block under certain circumstances, under certain depths of the Merkle tree, you could take one transaction that's already in the block and put two of them in there, right?

[05:04:33] And that can produce the same, because if you have an odd number of nodes in the Merkle tree, you just repeat the last one twice. And that's where the problem comes from. But two transactions, and this is one of the two types of malleation, but two of the same transaction in the block, you read one, you read the other, you hash it, and it produces the same hash as if you only had one. But now you've got a duplicate transaction in the block that makes the block invalid.

[05:04:59] So in order to know that, you have to, this is not, the 64-byte issue doesn't resolve this one. So this issue is always there, whether or not you have 64-byte transactions or not. You can have a duplicate hash in the block. So you have to mitigate against that. And if it does happen, it means you have a Merkle-ized block. Now, you can either throw out one of the transactions and reconstruct the original block and proceed on, or you could just drop the peer, which is what we do, and wait till you get a real block.

[05:05:42] But you obviously don't want to store the hash of that as invalid, because you don't know if it's invalid, because it was a malleated Merkle tree. So that problem doesn't get solved by the 64-byte thing. And guess what that costs to produce? Nothing. There's no mining. There's nothing. And you can produce an infinite number of those. So it doesn't solve the core problem. That was another example, another one of the examples used. And then there's the fact that with a 64-byte, the reason a 64-byte transaction is an issue, because you can take one transaction that actually the serialization of it is two nodes in the Merkle tree, and you basically fool the Merkle tree computation into believing there were two transactions there.

[05:06:37] Hard to explain, and I can't exactly remember the details, but that's basically the idea. And in order to do this, you have to actually mine. You have to mine a coinbase. And to mine a valid coinbase for this that fits into the Merkle tree and makes it all work requires like 2 to the 24th instead of 2 to the 256 or something. So it's a lot, but not overcomeable. It's viable. And so in order to prevent this 64-byte transaction issue from being an issue, one of the things you can do is you can just check the coinbase to see if it has a null point, which means the first input of the coinbase transaction has an index of all 1s and a hash of all 0s.

[05:07:25] I don't know why Satoshi decided to just send all this garbage over the wire. But the first input of every transaction has to be predictable garbage. Why not just not send it, not even have a transaction for the coinbase? I don't know. It's just easier code to write. But we haven't. And so the first thing in the block body that you encounter is the first bit of the point of that value. You encounter the, I think it's the index first, and then the hash might be either way.

[05:07:57] So in other words, the very first thing you're reading in the block, in this potentially bad block, is the coinbase point, the one thing that you need in order to know whether this could have been a malleated block. If that's a null point, it's computationally infeasible for it to have been 64-byte malleated. And I showed them this. It took me multiple iterations to get to the point like, look, if you want to be able to take the block and invalidate it quickly, disabling 64-byte transactions does not do that, because in order to know the size of any transaction in the block, you have to deserialize the transaction, which means all the way through all the inputs, all the outputs, all the scripts, everything, and then you have to do it to the next transaction and the next.

[05:08:42] You have to deserialize every single transaction in the block, one of the most expensive operations during download. And then that's when you know whether there was any 64-byte transactions. But what my implementation does, what we do today, is we look at the first 36 bytes of the block, and if that's a null point, we're good. It's not malleated. If it's not, it's invalid anyway, right? It's got to be a null point.

[05:09:11] John Carvalho: So I showed them that. So is this what they're going to do instead?

[05:09:14] Eric Voskuil: So I don't know. I think they'll keep doing things the way they... What they actually do is like a double validation. They don't isolate this check. They do block check twice so that they know... They actually took... So somebody saw that they were calling block check, which is the lower-cost validation. It's the static validation, right, of the block. They were calling block check once, like right after download or something, and then later before storing, they were calling it again. Now, some wizard noticed that this was redundant and took one of them out.

[05:09:45] Turns out that that second one was unknowingly guarding against this issue. So they had this flaw. They had a fork, and they fixed it. So that's... I think what they're doing, the way they fixed it was to just re-institute the redundant check. So they could certainly make that more optimal by just writing a simple check that says... Take the second one out and write a simple check that says this starts with a null point. The reason they don't do that is because every time they change something that's material...

[05:10:18] There's risk. And that's what happened. They changed this simple little thing, like a redundant check that shouldn't have been there, and something unexpected happened. And, you know, the same thing happened with the [unclear: inflation bug]. It was like a simple little thing, you change it, because it's very hard to see. If these

[05:10:34] John Carvalho: Small little things are so hard to keep track of the reactions, like, how could we ever pretend that a complex soft fork is

[05:10:42] Eric Voskuil: Safe? How can we contend that any implementation is safe, right? There's all kinds of changes that happen in the code between iterations. And, you know, it's not like there's one implementation of bitcoind. There are hundreds of implementations of bitcoind out there. And, you know, dozens, at least, that are released. And they fork each other every once in a while. And it's, to my mind, much more likely that you're going to fork because the logic is opaque, right? It's just, that one just worked because of luck.

[05:11:13] Or, you know, like, why does these things don't look like they make sense? They're hard to understand what's going on. I mean, you try to get your head around things like...

[05:11:25] John Carvalho: Covenant?

[05:11:27] Eric Voskuil: No, just simple basic, you know, day one stuff, like OP_CODESEPARATOR. Like, take a look at FindAndDelete. If you had no idea what that was supposed to be doing, you would have no idea what it was doing. You'd be like, what? What is this? And, you know, I don't know how many times I rewrote FindAndDelete till I really figured out what it was doing. And then I said, this is fucking stupid. And I took it out, and I rearranged all the code. And I was like, oh, this is what he's trying to do.

[05:11:57] This is the premature optimization of doing it this way, right? It's just the way the code is written. And it's super fragile. And it's, you really have to understand it to fix it. And that's, you know, it's risky if you don't really understand it. And people come in and they make a little change here, a little change there. Boom, it just blows up. I did this when I started working on libbitcoin. I broke stuff. I'm like, what's that? So Amir, he rejected one of my pull requests because I had fixed the error handling in some consensus code.

[05:12:32] And it was stupid. The code was stupid, but it was necessary because Satoshi's implementation was stupid. And I was like, OK, that needs a lot of, like, clearly defined code that makes it clear what's happening there, because people are going to keep removing this and keep changing this forever because it's dumb. And there's a handful of things in there that are like that. But most of it is just the way it's coded is dumb. The actual design intent is fine. There are some, like, here's another example.

[05:13:14] The order of transactions in a block in the Merkle tree matters. Not for any important reason, not for any reason, really, except Satoshi just took a shortcut. It wasn't even a shortcut. So if you're going through a block and you're looking at the transactions, and you're accumulating the unspent outputs, which we don't do, and you're looking at inputs and outputs, and all you care about is the net unspent outputs, what you're doing is you're matching inputs and outputs. You're putting them on a queue, and you're popping them up.

[05:13:54] And you're just doing this on one block, the new block that came in. Well, if you do it such that you read a transaction, you push the outputs, and you pop the inputs, and then you do the next one and the next one, what's going to happen is inputs that spend outputs in that block, if they don't spend ones that occurred prior, they don't get seen. The spend of the input to the output would not get seen because you're using a stack. You're pushing outputs, popping outputs, pushing outputs, and they have to come in order.

[05:14:25] So it's not a total ordering. It's a partial ordering. Anything that's spent within the block has to be spent prior to the input that spends it, has to occur in the block prior to the input that spends it. So initially, I implemented in C++ a standard for each loop, which is parallelizable. In other words, if the compiler wants to, it can parallelize the implementation. And I hadn't actually parallelized it yet. It just makes sense to write things that way. And I parallelized the iteration over the inputs and outputs, which wasn't doing it.

[05:15:03] We weren't – yeah, I think it was like maybe looking for double spends within the block or something like that. There's a reason you do this aside from just accumulating the inputs and outputs. And I didn't require any order. What I did was I read all the transactions and pushed all the outputs on a hash map, and then guarding against duplicates, which basically guards against having any duplicate transactions at the same time, and then took all the inputs and then correlated the inputs to the outputs. And that's a consensus break because it doesn't impose that order, that unnecessary order.

[05:15:42] But it's an order. And it was [unclear: Dave Hilbrand] Or somebody who's like, he had encountered this problem once before when a miner did something similar and he pointed it out. He's like, hey, that's it. But I had this very clear list of consensus rules. We're marching down through them and we're looking at the code together and he's like, boom, you know, like there. So it was very obvious and easy to see. Every consensus rule has a name. It has a little piece of code and it does its thing as it's marching through the block.

[05:16:07] But those things can happen when there was no – so what I ended up doing was I wrote a function that all it does is check the block to make sure that any spend is in the block is spending a transaction prior to it in the block. So it's not like – because that was a behavior that was just a side effect of how he wrote the code. He wrote this loop to do one thing and it imposed this order unintentionally. There's no reason for it. And so I wrote a rule that imposed that with a name on it that says no – what is it called?

[05:16:44] No forward references. So if there's a forward reference, if an input spends an output that's forward of it in the block, it's a consensus break. There was nothing like that in core code. There's nothing that says no forward. It's just hidden in the behavior of the code, right? This is a requirement. So by pulling those things out, documenting them in the code, not in comments, right? This is in the code. There's a function here that says this has to pass, this has to pass, and all these things are just a nice long list.

[05:17:08] Not even a long list, not very long. They all have to pass or it's invalid. And then you look at those and you go, which of these actually makes sense? Like, they're here for an actual economic security whatever reason. And several of them are there for no reason, right? There must be one Coinbase, no reason. There must be only one input in the Coinbase, no reason. The input must be null in the Coinbase. There's no reason to have any inputs in the Coinbase. There it must be first, single, single input and have a null point.

[05:17:39] None of those are necessary. You could just accumulate all the all the all the transactions that don't have an input, have no input on some of them, have inputs on other ones, accumulate all their outputs. And that's the total spend and accumulate all the all the others. And that's the you know, all the I'm sorry, that's the total claim on the on the block. Right. All the outputs of the on the Coinbase and the things that have no points. So it's much more general. You have a lot fewer rules, right?

[05:18:04] Simpler to implement. But, you know, it's not like that. So we have all these rules that really don't serve any important purpose.

[05:18:13] So I'm just I'm just rambling on different stupid aspects of of implementation. But implementation drives a lot of the thinking around these things and all of the reasons that they had given for banning the 64-byte transactions had to do with making their own implementation easier based on the way they saw it. Right. When I pointed out these things, they were forced to accept that even if it might make their own implementation easier, it didn't make any sense to impose these rules. So it comes down to. Yes, I said I said, yeah.

[05:18:48] Yeah, I understand that it would save like about 100 bytes on average download for an SPV wallet if you if you invalidate 64-byte transactions. Of course, the CPU cost of invalidating all the 64-byte transactions in the block is pretty small. It's pretty trivial. You know, maybe maybe maybe 30 seconds on the whole sync run. But I think it's probably still a wash.

[05:19:09] John Carvalho: It's really not worth it.

[05:19:10] And then why is Bitcoin core node optimizing for SPV? I guess

[05:19:14] Eric Voskuil: I don't know. It was a reason to save this, save the soft fork feature. But I think it was acknowledged in the summary recently that this one before it was like so important they had to do it. And everybody agreed. Now it's like, you know, they're no longer listing any of those reasons. And it was it was stated, again, I give these guys more credit than the guys before. They stated that this probably wouldn't rise to the level of activation if it was a standalone soft fork. Right. Nobody nobody would support a soft fork in Bitcoin to do this.

[05:19:46] So it's only happening because it rolls up into other things. And so, you know, the natural reaction is to go look at the other things and go, do these make sense, too?

[05:19:53] John Carvalho: Yeah, because this makes me think, OK, like if if the attitude is, hey, we're all looking at this as an inevitable soft fork. Let's shove in all the pork we can. Yeah.

[05:20:05] Eric Voskuil: There's I mean, there's I think there are reasons to to kind of roll up the cruft and clean it up. You've got to be careful, you know, even doing so, like like there's a time warp bug. And from my recollection in our code. So so we have Litecoin support prior to like MWEB. Right. Goes way back, like seven years or something. And in the code, there's like two changes that I can. There's only I think it's only two. So Litecoin is so similar to Bitcoin that if you if you generalize the numeric parameters, like the things that control for block period, things like that, if you move those into config, like there's a handful that we moved into config, which we had already done for being able to do TestNet, TestNet3 anyway. And not Signet, but anyway. So so we'd already kind of done that anyway. But we had to write two, there were two code changes. One was scrypt versus SHA, right, for mining. So we had the scrypt library. Just one line of code changes that we were able to get to. Line of code, if this fork is active, we're forking in scrypt versus whatever. And if that code is active in the config file, then that gets run.

[05:21:22] And the other one was the time warp bug.

[05:21:27] So Litecoin implemented a time warp bug patch. And we have a fork for it in our code, which switches on that, change to the code if that's enabled. So if you want to run Litecoin, you change a couple of numbers in our config, and you activate those two forks. And to go to test net, you activate the easy blocks fork, which changes the block difficulty, so it's easy to produce blocks and some numbers. And that's it. It's really simple. So you can actually run the same binary without even recompiling against all these different variants.

[05:21:59] So that tells me that somebody had already thought through it and implemented and deployed a time warp bug fix. And I never really spent any time thinking through the complexities of the time warp bug. But I was kind of wondering, why aren't we doing it the way they did it? So I don't have to implement another fork in my code. But I don't really know. So that was one that there's a legitimate issue there. It's kind of obscure, esoteric, but real. And that one probably should get fixed at some point.

[05:22:34] So there's another one that has to do with making very expensive to validate transactions. I don't know if you guys remember, way back, there was a quadratic OP_ROLL bug identified. So somebody identified that you could force 1,000 OP_ROLL operations in one transaction, one in one script. And it's not inherently, it's not a bug. It's the way it was designed. It works the way it works. But in Bitcoin Core, the stack, which is just Bitcoin script is a stack language, which means you have op codes, which you're just running through.

[05:23:19] There's no looping. There's if, and there's conditions, but there's no looping. So you just run through your list of op codes, and you execute them. And the state that's maintained between those op codes is the stack. We've got a primary and alt stack. And you run through the script, and you're pushing and popping stuff off the stack. Now, in theory, stack language is pure stack. You push and you pop, and that's it. You can't read way down to the bottom and in the middle and stuff like that.

[05:23:48] But the way Bitcoin Core is implemented, it does a lot of cheating on the stack. If it needs to inspect the second item on the stack, it doesn't pop the first, pop the second, inspect it, and then push them both back. It's an optimization. It's kind of a hack. So when I originally rewrote the script implementation in libbitcoin, I implemented it as a pure stack. In other words, you only got to push and pop. You couldn't see what was down in there. And then did optimizations on top of that.

[05:24:19] And I did that so that we could, one, ensure it was a pure stack implementation, and two, that we could provide a variant of it without whatever these fairly minor optimizations or even determine they weren't necessary and just run a true stack so that people looking at it from an academic perspective could better understand how it works. That makes it much easier to understand the op codes. Anyway, so OP_ROLL takes this stack, and it pulls an item out of the stack and pushes it, moves it to the top, which shifts all the other items down in the stack or something close to that.

[05:24:52] And because the stack can gain a certain size, which you can kind of impose through your hacky script, you create a big stack, and then you start moving as much as you possibly can. And all those shifts require essentially rewrites of the stack, and that can get very expensive over time. The reason it's expensive is because of the use of a standard vector to implement the stack, which is contiguous memory. When you move something out of the middle, you have to move everything up. You can't just delete something, right? It's contiguous memory. So if you have 1, 2, 3, you pull out 2, 3, 4, 5, everything after it has to be shifted up in the memory. That's hugely expensive. Although if you implemented it using a list, which is a linked list, it's trivial. You just pull out the element of the list and readjust the link, standard list delete. So why don't you do that? Well, because lists have pointers, and therefore more independent allocations, it's slower than a vector if you can get away with a vector. So OP_ROLL is quadratic, which means it can be very expensive.

[05:26:00] And it is very expensive. I think there's nothing stopping this presently. So I looked at it, and everybody looked at it and said, there's really no way to solve this. And I went, wait a minute, what are you talking about? If you implement the stack as a list, it's solved. It's no problem. And so what I did was when we implemented, when we implemented, did this reimplementation of script work a couple of years ago, stack got templatized so that it takes, as a template parameter, the container that it uses to implement the stack.

[05:26:33] So the entire script processor is templatized on a couple of parameters. And one of them is the, actually maybe only the stack. So you can templatize it with a stack, sorry, with a vector, or you can templatize it with a standard list. They have basically the same API signature. So they're interchangeable. You just compile with one or compile with the other. So what do we do? We compile both, right? I don't know, it's like an extra 500K. And by the way, our whole implementation is much smaller than Bitcoin Core. So single file binary, right? So we compile both and we take a look at the script.

[05:27:05] And the script has an OP_ROLL in the op codes, which we determined during parsing. We call it a roller script. We just execute on the other script engine, on the other processing engine. So it's no problem, right? It would be, if we did it for all script, it would be, we would take a performance hit. If we do it for just OP_ROLLs, we're probably taking a performance hit on most of them because most of them probably are not malicious, right? But that one that comes along and takes like 10 minutes to process, we're not going to get hit by that, right?

[05:27:37] We're just going to blow right through it. And we, you know, our validation is super fast. So these, again, a lot of the decision-making around even consensus stuff comes back to your implementation. We looked at it and said, that's a perfectly legitimate op code. There's nothing wrong with it. I don't want to see somebody banning it down the road, so I'm going to implement it properly. So it's performant in both scenarios.

[05:28:00] John Carvalho: Is this the same type of transaction or are there more when people talk about like being worried of direct submission to miners because they can include non-standard transactions? So miners need to know which types of non-standard transactions. Definitely

[05:28:14] Eric Voskuil: A non-standard transaction. Yeah, it's definitely a non-standard transaction. I don't think OP_ROLL is standard, standard op code. But, you know, people can mine their own. So there's no stopping that, so it's silly. Policy is dumb. We don't implement policy.

[05:28:31] John Carvalho: I remember when, I think it was Marathon Mining released their direct submission service.

[05:28:37] Which had been produced for a long time, right?

[05:28:39] And I think it was the guys from Spiral, Matt and Steve Lee, were like super scared. And I learned about this later. And they ended up contacting Mara saying, hey, are you guys watching out for non-standard transactions? And they weren't. And so it was like, yeah. Why would you?

[05:28:56] Eric Voskuil: Why would you? It's dumb. It's just dumb. Well,

[05:29:01] John Carvalho: Because they could cause nodes to freeze from taking too long.

[05:29:05] Eric Voskuil: So one miner watching out for them, while you don't know what any other miner is doing, doesn't help, right? This is what I mean by obscurity, security, right? It's like Dandelion. It doesn't help to pretend there isn't a problem. There's a problem. The answer to this particular problem was to templatize your script process, which would be a horrendously difficult thing to do in Bitcoin Core, right? But proper implementation or abstract implementation is trivial, inconsequential. So I mean, it's a good point. But I point out, we only implement policy for DoS purposes.

[05:29:42] And that's just fee rate. So that if we take free transactions that wouldn't cost anything if they got mined, then we would be easily overflowed in terms of disk or memory. So that's what we do. And that's always been my policy for 10 years. Why would we implement policy? It doesn't make any sense. They're trying to stop things from happening that they cannot stop. And all they're doing is creating a bigger and bigger reward for the person who decides to not do what they want them to do.

[05:30:14] It's better to let the little problems creep along and people start fixing them, right, like I did. So there's this other problem in this consensus cleanup, which has to do with—it's similar to the OP_ROLL problem. It's definitely not the same problem. It has nothing to do with the stack or anything. But there are expensive transactions that hadn't really been anticipated or talked about or something like that. They can get really expensive. And it wasn't clear how to deal with them. And so there have been a number of proposals.

[05:30:50] I've read through it a couple times, and there's no easy answers in these particular cases, but they probably should be dealt with. And this is one of those cases where I go, well, I'll defer to these guys who are spending all their weekend hours working on this question. They're smart people, and I don't see anything wrong with their arguments. I'm just going to be an observer in this case. So this is the way it works. There's certain things I know. I know a lot about this OP_ROLL question because I did the work.

[05:31:18] I coded the implementation. I know about this 64-byte issue because I had just done the work. And that's what happens. You have a lot of different people working on a lot of different things, different implementations. They'll have different areas of expertise. And when they come together, they can provide better input. When you have this monoculture, you just get, yeah, it all looks good, right? And let's do that.

[05:31:42] John Carvalho: The monoculture you're separated from because your behavior might cause your PRs not to be reviewed or merged in core. But because you don't submit PRs to core, you don't have to worry about that.

[05:31:56] Eric Voskuil: Right, right. And so somebody comes along and says, well, we want to ban more than three OP_ROLLs and whatever. I'm going to be like, why would you do that? Why would you want to fork to do this now? Because our implementation is super slow. What happens? Okay, well, we just ran through all these test transactions super fast. What's your problem? That's kind of how I look at it. It's better to have competing implementations out there that can show you other ways to do things. But part of that is that we're showing people how to do certain things differently.

[05:32:24] And it's very disruptive. Core can't adopt some of the things I'm talking about. Not without a major rework. So that now becomes defensive, right? We're going to protect ourselves by getting better performance by maybe changing consensus rules or changing a network protocol. So it works in our favor where it hurts us, right? Every consensus change that's unnecessary is difficulty for us because we maintain all of the history of all the consensus change. They just throw out the old code, right? It's done. Don't worry about that anymore.

[05:32:57] Every bit that like obsoletes the other bits, we maintain them both. We take out this one. This one's still active. So all the shit they did on BIP 30 where, you know, it's like that's when the database forked. And first thing they did was it was kind of a 13 block, you know, chain split. And it was like panic. We're going to contact the miners, stop mining. Now we're basically going to soft fork out all blocks that have more than, I don't know, 5,000 hashes or something.

[05:33:26] And so it was the quantity of hashes they determined which produced a certain number of database locks which caused the failure. Silent failure to basically invalidate the block. And so restricted the number of hashes that could be in a block. That was a soft fork. Later, made some changes, whatever, decided, you know, we didn't want to have this restriction. Fixed the problem and then took out the restriction. So that was a hard fork, right? Because they're now re-enabling what were previously considered invalid blocks. So we've got three forks in there for that, right?

[05:33:59] We got like, well, there's the initial fork, which nobody knew about, you know, which we didn't have, by the way, because they were based on LevelDB. And we had used and dropped LevelDB long before. And so we didn't have any restrictions on [unclear: how many hashes could be in a block]. So they would have forked off from us. And here's an interesting question. When they forked off from us at that point, who's running Bitcoin? Who's running BTC? We are. Because that fork that forked off from where we are, that got invalidated.

[05:34:34] I think that was the one that got, you know, those transactions went away. And we went back to the other one and then imposed this other restriction.

[05:34:42] John Carvalho: So this was the Berkeley DB change in like 2014 or so, is that what you're referring to? Was

[05:34:47] Eric Voskuil: It Berkeley DB to LevelDB? Or I think that's what it was, right? So yeah, like 2013. I don't know. We started in 2011. This was early for me. But I've gone back historically and looked at the BIPs and the code changes. And I've written code in there to impose the block hash. It's not the block hash. It's like number of hashes. Impose the hash restriction so that we can produce the same behavior. So you could take out the hard fork, still have the soft fork. You could take out the soft fork and still have the no fork.

[05:35:24] But then the question is, if you take both those out, what's the intended behavior? What was actually Bitcoin before that? So the hash restriction that the database was imposing wasn't the number that they put in. It was higher. I don't even know if anybody actually knew what specifically it was. They put in, I think, it was 5,000 restrictions. So before that, there was some arbitrary restriction. And it would have varied version to version. So the question is, what was the consensus? Nobody even knew what the consensus was.

[05:35:54] The code is not the consensus. What became the consensus was the rational behavior, which we had, which was no restrictions on the number of hashes in your blocks. That was the consensus. And this is why it always burns me when people say the code's the consensus. Time and time again, the code is not the consensus. The inflation soft fork that, you know... For what it's

[05:36:15] John Carvalho: Worth, I always say consensus transcends code.

[05:36:18] Eric Voskuil: The consensus is the consensus. And the code implements it. And there may be cases where the code does things that are weird. But people know about it. It's not a mystery. But when there's something in the code that nobody knows about, and then it does something that violates the human consensus, it gets fixed. It gets changed. It's not the code.

[05:36:37] John Carvalho: This is why I don't worry as much about mining attacks and people speculating about mining attacks is because not only is there not a lot of incentive, not only are they difficult, but consensus will transcend whatever glass hammer they choose to break on us. And so they can't take advantage of their attack without revealing their attack. And once they do, consensus will enforce, whether it be through code or through new code. Yeah,

[05:37:08] Eric Voskuil: I think consensus eventually wins. It doesn't mean

[05:37:14] John Carvalho: There won't be price damage temporarily or such, but just from reasoning it about it, that's how I think about it. Got any other questions for us, Vlad?

[05:37:30] Eric Voskuil: Push the six hour mark.

[05:37:35] All right, well, that's my cue. I'm going to hit the restroom again. It's been six hours.

[05:37:39] Vlad Costea: I was muted. Sorry. We passed the five and a half hour mark. So this is pretty good. We do have some questions. So I wish Eric was here because there's iCust007 in the chat and he said that he's running Bitcoin Knots and he wants to know what are the comments from Eric on Bitcoin Knots, if it's better than Bitcoin Core and why it's so fucking heavy in terms of resources.

[05:38:17] John Carvalho: All I'll say is why do you want to run the implementation by the guy who lost all his Bitcoin?

[05:38:23] Vlad Costea: Well, I guess he's mining with Ocean.

[05:38:28] John Carvalho: Yeah, I don't know. My impression of Ocean, my respect for Luke has gone down in the past year or two. The things with fixing the filters and censoring mempool transactions and the way they're portraying some of what's going on is Ocean as relevant or even useful. And when it's not like, I just don't think I don't know. I feel like there's he's leaning on a little bit of his reputation and a bit of, you know, people's interest in just blindly supporting him. And that that what they're doing is not really very interesting or relevant.

[05:39:11] Vlad Costea: I would not be this harsh because I know that Luke has been of this opinion for at least a decade. There was this other situation with the OP_RETURN wars. That's what they referred to them as with Counterparty and Omni when basically that was when the developers decided that they want to switch to Ethereum.

[05:39:34] The scandal, I'm not sure about the parameters. Maybe I should look up before I say this, but I know that the data size was restricted on Bitcoin to not allow these token issuers and people building on Counterparty or Omni to insert too much data into Bitcoin blocks and they were not happy about the limit. I think the limit was lifted with Taproot. And that's how it became possible for people to do these four megabyte ordinal inscriptions. But Luke has been pretty consistent in his views. It's just that now he found a business model around what he believes is his personal quest for purity.

[05:40:20] And honestly, John, I remember you're one of the first guys to run a 300 kilobyte node.

[05:40:27] John Carvalho: I never I didn't even know that he actually made a fork of that was 300 kilobyte. What I did was I was supporting his just mentioning of the idea of reducing the block size, partially because it's not something I had thought of before. And I thought it was an interesting concept to think about. And I was trying to reason about this was back 2017 or so maybe 2016. I was trying to reason about lightning network. And, you know, the idea part of the idea with that was, well, if we had smaller blocks, then people would be forced to use lightning.

[05:41:06] But generally, I'll say any of my support for that idea was, in my opinion today, out of naivety.

[05:41:15] Vlad Costea: So Eric, there's someone in the chat wants to know what you think about Bitcoin Knots, which is the client that's being maintained by Luke Dashjr.

[05:41:25] Eric Voskuil: I don't know, I just, to me, it's just another Bitcoin core.

[05:41:32] I don't think much about it. Well, what would I what would I think about it? I don't. It's, it's, it's just Bitcoin core with a few, you know, parameterization changes, maybe some trivial code changes.

[05:41:47] So now, I mean,

[05:41:50] John Carvalho: Why does your reader or your your your person in the chat? Why does he run Bitcoin Knots?

[05:41:57] Vlad Costea: Because he seems to be mining with ocean.

[05:42:01] John Carvalho: You need to run Knots to do that,

[05:42:05] Vlad Costea: I guess, or maybe it's part of the recommended stack. If you go on some page by Luke, he tells you that the first step is to download Knots and then spin up your Yeah,

[05:42:16] John Carvalho: Aside from any kind of personal judgment of Luke, I would just say, look, you're running an implementation that probably isn't haven't doesn't have a lot of eyeballs on it doesn't have a lot of, you know, maintenance and development put towards it. You're taking a fair amount of risks, in my opinion, you know, you're putting your trust into one guy, or I don't know how many people work on Knots, but I'm assuming not much more than one. You know, and why would you do that?

[05:42:44] Eric Voskuil: I just wonder, what, why would you do it anyway? Like, what's the what's the motivation? I mean, I've heard him say that it's more performant, but I don't think there's any significant performance difference. You know, I remember we were talking about the size of the DB cache, and, and for the UTXO cache, or maybe it's called DB cache, UTXO cache, when you're thinking and how that can affect performance. And I think it was somebody pointed out that Knots changed that limit. Right. In other words, they took the pull request.

[05:43:13] To allow that limit to be larger that Bitcoin Core didn't take, and it's not a consequential change. These are tiny things in the big scheme of things. And I think probably the main reason why he's got his own thing is so he can make tweaks like that, performance changes or policy changes that may not be available. I don't know, but there's not significant differences. I

[05:43:41] John Carvalho: Can definitely be wrong about this, but I almost want to say, didn't Knots first come about because Luke wanted to be able to introduce censorship to have ban lists? Isn't that why he started it?

[05:43:54] Eric Voskuil: I don't know. It's been a while. He's been around for years.

[05:44:00] But if there were significant advantages to Knots, they'd just be pushed into Core. So these aren't really what I consider significant things from the perspective of a node developer. These are more probably differences in philosophy in terms of policy and configuration parameters, maybe some tuning for mining.

[05:44:22] John Carvalho: Oh, that's why. They run it because they want to fix the filters. That's why they run Knots. They want to pretend that they can censor the NFT transactions and such. I

[05:44:37] Eric Voskuil: Do see a good number. I think pretty regularly on Mainnet, I spit out the nodes that connect on the console and I see a pretty good number of Knots nodes, I don't know, maybe a few percent, which is more than most of alternate nodes, although you can never really tell by looking at that for sure.

[05:45:04] Vlad Costea: Oh, yeah. He said, yes, he does want to fix the filters.

[05:45:11] John Carvalho: Does he understand why that doesn't mean anything?

[05:45:17] Vlad Costea: Well, I'm not sure, but it feels like, I don't know, when this, there's this guy, Unhosted Marcellus or something, who started this movement on Twitter, seems like he had this sort of epiphany and he found himself in the middle of a personal crusade to pursue purity in Bitcoin, to maintain its usefulness or something, to keep the spam away. It's like...

[05:45:43] John Carvalho: That's the pursuit of censorship is what that is.

[05:45:46] Vlad Costea: Yeah, I know.

[05:45:48] Eric Voskuil: No, censorship is perfectly legitimate in Bitcoin. I mean, there's nothing wrong with that. Everybody, all miners censor and they choose, I define censorship as selective, subjective as opposed to objective selection of transactions for confirmation. And all miners must select, sorry, subjectively select transactions for confirmation because they're, the only objective way to do it would be to take the ones that produce the highest fee. Right? That's an objective way to select which transactions, even if there's no spam, how are you going to do it? Right?

[05:46:23] John Carvalho: You have to order...

[05:46:24] Well, wouldn't there also, maybe this is a little too philosophical, but the miner might also be inclined to think about the long-term fees. In other words, you could objectively analyze which transactions have the highest fees, but if for some reason those are types of transactions that are, I don't know, somehow going to affect the overall long-term usage of Bitcoin, then you might not want to include those transactions for some other longer-term speculation.

[05:47:00] Eric Voskuil: Nevertheless, it's not computationally feasible to produce a set of transactions at any given moment or for a potential block that satisfies any objective criteria, except for the fact that you've randomly chosen them, right? You've arbitrarily chosen them. Bitcoind uses a knapsack solver to produce its block template, which is just grab whatever you're seeing, sort of, because it is an NP-hard problem to optimize for anything. My point was just that there's no purity in that process, right? You could not accept anything that meets certain criteria.

[05:47:41] That's policy. That's subjective, right? The only objective policy would be it satisfies the consensus rules. That's very objective, but then you still have to take a subset of what's mineable, and that becomes subjective again. Censorship occurs on a regular basis, and if it was a problem in Bitcoin, then we'd have a big problem. Censorship itself is not a problem because the presumption is that your odds of getting many blocks in a row are pretty damn slim, and eventually, somebody's going to mine the transactions that you're not mining, and if they're not getting mined, the fees are going to rise, and eventually, somebody's going to be incentive to mine them.

[05:48:21] The only time it becomes a problem is when it's enforced by a majority of hash power, which is both the situation you have in the case of soft fork enforcement and in the case of state censorship,

[05:48:36] John Carvalho: Right? So basically, unless you convince all miners to censor ordinals, then censoring it in the mempool level is just performance art. You can't

[05:48:48] Eric Voskuil: Just not only do you have to, well, I mean, you can't convince all miners that presumably the guy that's creating the ordinals is going to mine himself, right? And so eventually, somebody comes along and mines one, and you want this pure system. What do you have to do? You have to convince majority hash power to not mine on that block. That becomes majority hash power enforcement of censorship, which is indistinguishable at that point from state censorship, right? That's the kind of censorship threat, is that you can't get your transaction confirmed no matter what, because the majority won't build on it.

[05:49:19] That's what a soft fork is. I'm sorry, that's what soft fork enforcement is, and that's what makes a soft fork non-disruptive when it's deployed if you have enough hash power not willing to build on otherwise valid blocks. So...

[05:49:35] John Carvalho: So yeah, this leaves you in a situation where if you try to, quote unquote, fix the filters, you have one of two possible outcomes, that you have no effect, and you've wasted your time, and you've done performance art, or somehow you figure it out how to make censorship more efficient.

[05:49:52] Eric Voskuil: Yeah, that somehow, if you figure it out, is a soft fork. You've imposed a soft fork where the majority hash power will not mine on non-conformity. Oh, what I mean

[05:50:01] John Carvalho: Is that the pursuit for purity ends up being a pursuit for better censorship in Bitcoin.

[05:50:07] Eric Voskuil: Right. I mean, it's totally a soft fork. I mean, there's two aspects of a soft fork. One is the enforcement of majority hash power, and the other is activation of a rule in nodes, right? So what typically happens is miners, we didn't used to do this, but we got to the point where we get smarter on it and set a fairly high threshold. Once that threshold has been signaled, we assume that miners are going to honor their signals and censor. And at that point, it's safe for all nodes to activate the rule so that if miners stop censoring, everybody's significant part of the economy is now rejecting blocks that are non-conforming.

[05:50:49] So that's activation. Censorship coupled with activation is how we get these things deployed. And you can certainly have a soft fork that consists of invalidating transactions that are non-standard. Just get rid of all non-standard transactions, or ones that have OP_ROLL, or ones that have too much of an OP_RETURN, too much data after an OP_RETURN, for example. But this has already been looked at many times. There's so many ways to put arbitrary data into a block that it becomes very counterproductive.

[05:51:29] John Carvalho: It's also like, we're not even discussing like, why? In other words, okay, what was the motivation for wanting Bitcoin to be pure or such? Like, I feel like the motivation was that the blocks got full, and they didn't like that the blocks were full. And so, because fees went up, or because they wanted to, you know, they wanted the block space. And so what are we going to do every time there's a type of Bitcoin transaction that is valid, that is the most popular type, but not the most popular one?

[05:51:58] You're going to advocate for censorship of that. Like, I don't understand what long term logic is here. Like, okay, now we hate ordinals. But then suppose we need a soft fork and covenants, and then covenants fill all the blocks. Are those same guys going to want to filter out covenants? Like, what is the logic?

[05:52:17] Eric Voskuil: Maybe bare multisig fills all the blocks or something. I just don't, I really don't care that much. Like, you know, you and I have had the same thing about RBF, right? Like, that's another form of policy, right? And going way back before RBF, before even the first RBF thing was deployed, I turned on, no policy. So I've always taken the perspective of, if it conforms to the consensus rules, it's valid, right? And you're not going to be able to control who mines what, unless you're the state, and you get majority enforcement power.

[05:52:56] So I really am not going to work on something that is not enforceable. And I can understand the motivation of

[05:53:05] John Carvalho: I learned a lot from you about how to reason about that situation. But I think there was a lot of nuance in that, in a lot of other learnings in that kind of mempoolfullrbf war. And just that in the end, what I was just trying to show is that core kind of supposedly has a policy of if something is controversial, that it should be held and not, you know, merged in and going live. And there's obviously always been controversy around RBF around zero confirmation transactions. And I found I was very, very disheartened with the way I was handled by core when I was trying to, I had a core dev help me make a PR to undo mempoolfullrbf as an option.

[05:53:58] And I didn't quite know when I started about all of this was, you know, the stuff that you taught me about it, and that, you know, there was this is just policy stuff. And we shouldn't even mess with policy and have policy. That was interesting to learn. But in the end, like I felt what they were doing was violating the user space for a speculative kind of nannyism. In other words, zero confirmations were never safe. And so we're going to make it we're going to remove first scene so you can't do them for sure.

[05:54:28] And it's like, okay, but what was the trade off exactly? Because nobody got anything out of mempoolfullrbf, I can, I still can choose the RBF. It's, it's a,

[05:54:38] Eric Voskuil: It's a, it's a, it's a reasonable precautionary improvement to the to the network protocol. Because you can say nobody got anything. But the way I've always looked at it is if you put something in there. So this is exactly the same. It's not

[05:54:56] John Carvalho: Enforceable, either.

[05:54:59] Eric Voskuil: Exactly the same argument for Dandelion. Exactly the same argument for mixing, right? You put something in there that purports to provide a certain level of guarantee that doesn't actually provide it, but people just haven't figured it out yet. What happens is people build up infrastructure on that, and they did, they built up infrastructure on on zero-conf. Now, in the earlier days, people didn't think that people were going to really do that. Right. But then they did. And there was this back and forth. Like, at some point, this is the way I look at it. [unclear: It's pretty much] Infrastructure built up on this, that it's going to be catastrophic.

[05:55:41] John Carvalho: But that wasn't what was happening.

[05:55:43] Like what was happening was merchants, merchants were aware of the risk. And what they were doing is they were they were putting a price on the risk and offering credit as a service.

[05:55:54] Eric Voskuil: Well, so in this case, right, if that's true, I can submit a transaction to a merchant, and the merchant is saying, all right, I know you can double spend that transaction. Maybe you get a lot of hash power yourself. Maybe you're a g-hunt. But I'm going to price in that risk, et cetera, et cetera, et cetera. So in the case with no RBF mempool, but that's the case anyway, right? So they can still price in that risk, right? But

[05:56:26] John Carvalho: The difference was it changed double spending to be something that could be done by amateurs.

[05:56:33] Eric Voskuil: Amateurs could always do it. They just had to,

[05:56:34] John Carvalho: The miners just had to get it. Not with any reliability. It was actually pretty difficult with first seen. I worked at Bitrefill, and I think that the whole time they accepted zero-conf transactions, there was one attempt at double spend.

[05:56:53] Eric Voskuil: Yeah, but again, that's what I mean. We're building up this house of cards, and somebody comes along and says, I'll take, I'm a miner, I'll take any transaction you send me, the fee's higher, I'll replace. Doesn't require a core to do anything, right? Doesn't require, all it requires is a big enough miner to say,

[05:57:06] John Carvalho: Eh. Right, but the difference is you have to get that confirmed, you know, you have to get that confirmed fast enough to affect the situation. Like you don't have a guarantee that you're going to get that double spend.

[05:57:17] Eric Voskuil: So I send it off to the miner and I give you one, right? And you've got now what, like a one in, you know, one in 10 chance of getting double spent. Maybe, you know, half the miners decide doing it.

[05:57:28] John Carvalho: And you also have the factor that double spending is seen as illegal, and your transaction with a real life entity, and so you have a deterrent as well. So this is why in practice, we had a first seen mempool, we had a first seen mempool policy, and we had the ability to offer zero confirmation transactions as a service. Now, you can say that, oh, well, you don't know how to properly manage your risk in that service, but that's my problem, right? It's still your problem.

[05:58:02] Eric Voskuil: It's just not, we're just not as engineers, right, telling people that there's any security in this. There isn't, there isn't.

[05:58:13] John Carvalho: But this had been the policy in Bitcoin for how long until it was like formally removed? Too long. Way too long. I took

[05:58:23] Eric Voskuil: Out this, we never had, Bitcoin never implemented. But RBF

[05:58:28] John Carvalho: Isn't a policy that's enforceable either. The thing is, I find the whole argument to be [unclear: circular]. There's no policy.

[05:58:34] Eric Voskuil: You just take all the transactions.

[05:58:38] John Carvalho: We need RBF because miners will always take the highest fee. Okay, then why do you need RBF?

[05:58:44] Eric Voskuil: What you're calling first seen is a concept that doesn't exist in Bitcoin. There's no first seen. No, no, I'm talking

[05:58:48] John Carvalho: About RBF now. I'm just saying as a concept. When you

[05:58:50] Eric Voskuil: Say the alternative to RBF is first seen, I can send out two transactions to the network. Some are going to see one, some are going to see the other first. There is no first seen, right? So that's always the case. It doesn't require any RBF. You can have a 50-50 chance right there. I just send them both out at the same time.

[05:59:09] John Carvalho: I don't think in practice it plays out as 50-50.

[05:59:12] Eric Voskuil: Do the math. I mean, how could it not?

[05:59:15] John Carvalho: Well, I mean, the only math that we had was examples, right? And the examples we had were much, much less. Because nobody was doing it. And we couldn't pay people to do it. RBF

[05:59:28] Eric Voskuil: Requires low value transactions. Nobody is taking a, you know, a new Tesla on their fucking, you know, zero-conf. They're waiting for six, five,

[05:59:38] John Carvalho: You know, something. And that argues my point, too, though. Like, these are lower value transactions. The reason

[05:59:43] Eric Voskuil: You're not seeing it is because the value is low, right?

[05:59:47] John Carvalho: That's it. But most are dealing in low value transactions. Not that

[05:59:51] Eric Voskuil: You're not seeing it because it's difficult.

[05:59:53] John Carvalho: Like, keep in mind, the example here is Bitrefill and similar companies. We're not talking about $2,000 sales. We're talking about $20 sales. It was not worth the cost.

[05:59:59] Eric Voskuil: If it becomes worth the cost, if the reward is worth the expense or the effort, there's no real computational cost, right? To do it, then people are going to do it. So the more infrastructure we build on the stuff and the more dependent the system becomes on it, the more disruptive you can become, even just as a random threat actor who's trying to disrupt the economy, right? The

[06:00:24] John Carvalho: System was detecting double spends, and it had the ability to turn off when double spends happened. And so this was a service. I mean, I understand. I'm not arguing they're safe. I never wanted to argue that they were safe. I wanted to argue that they were manageable.

[06:00:42] Eric Voskuil: You can still take zero-conf transactions.

[06:00:44] John Carvalho: No, but now anybody can submit it with a guarantee.

[06:00:47] Eric Voskuil: Anybody can do it all the time.

[06:00:49] John Carvalho: No, but it was not as certain before. Look,

[06:00:52] Eric Voskuil: It's just a losing arm. There's no security in it. You can argue all you want about how often you saw it, but there is no security.

[06:00:59] John Carvalho: Then will you concede the same thing about RBF, that RBF is also not? I

[06:01:03] Eric Voskuil: Don't even care. RBF to me is not even a relevant factor. RBF is just another form of policy that we don't implement. So you agree

[06:01:12] John Carvalho: That, in other words, RBF doesn't need to exist either.

[06:01:15] The first scene shouldn't exist, and neither should RBF. What you're calling RBF,

[06:01:19] Eric Voskuil: So for example, libbitcoin does not replace things. So it's not a concept we have, because we don't have a mempool. So we don't discard stuff from the mempool, because we don't have a mempool. And so this is what the mentality that comes about when you think about everybody always thinking that everybody uses the term mempool. It's not part of Bitcoin. It's part of bitcoind. It's part of Bitcoin Core. The fact that Satoshi decided it was wise to store an arbitrary number of arbitrarily sized transactions, at least up to like 4 meg or 1 meg at a time, in RAM is not reasonable.

[06:01:57] It just doesn't make any sense. It's like storing an arbitrary number of bans in the ban list until it overflows. Well, guess what? It's overflowing all the time now. Maybe this week it's OK. But all of the major discussions I've seen on Bitcoin dev, not at all, but a significant fraction of those discussions have been about overflowing mempools. We don't have overflowing mempools, right? And this was very, very predictable. From the start, you could predict that if you're going to store transactions in RAM, you're going to overflow your RAM.

[06:02:30] And so you're going to get into page swapping or something, and eventually they're going to end up on disk. So the question is, and if you're objective at the only reason people should be storing transactions is because they're mining. Relaying to miners is great, but ultimately the only reason anybody needs a transaction is because they're mining. Now, you can argue about zero-conf, but I'm arguing that that's not secure, so I wouldn't build that into my node for that purpose. It's interesting to know that somebody submitted a transaction.

[06:02:58] That's nice to know. So informationally, it's useful. But ultimately, the transactions are for the miners, and the design principle that we operate under is miners want to make as much money as they can, because if they don't, they'll go out of business. Other miners will put them out of business. And ultimately, fees are going to be all the money they're making, so this matters a lot. Miners need to make the maximum fees they can make, and how are they going to do that? Are they going to do that by having a tiny little bit of RAM, stuffing a handful of transactions in there, and then, boop, one comes in, it pushes out another one, and everything goes to shit because they just lost a whole bunch of money because those are all connected somehow.

[06:03:34] That's what's happening with mempool policy right now. And I said, we don't implement policy except for DOS. So what DOS policy do you need when you take in transactions? We take in a transaction and we put it on the disk. That's what v3 does. This goes back like seven years, right? We put the transaction on the disk. Well, if we do that for any transaction, the transaction has to be valid. In other words, it has to connect to another transaction we have. The script has to execute.

[06:04:00] And it also has to be, there's certain context that's required for validating a transaction for the block. In other words, when you take a mempool transaction, there's no such thing as a valid mempool transaction. The transaction can only be validated by block. That means you have to make certain assumptions when you accept it into the mempool about what the next, or what the future block will be that it's going into. In other words, if the top height, if there's a certain height with a certain timestamp, with a certain median time past of previous blocks, you have to take that, roll it forward and make an assumed block, basically, and say this transaction, and this also has to do with fork activation, things like that, this transaction is valid in that future assumed block context.

[06:04:43] But that may not be the block context it validates in, right? So what you do is you take that transaction and you validate it in the context of a block, and you make sure it doesn't overflow things like the total block size, it's not bigger than it can be to be in a block, SIGOPS, things like that. And then you sort of put it on the disk. And if you don't have some constraint, you'll fill up your disk as soon as somebody decides to throw you as many transactions as they can think of.

[06:05:09] So you put a fee limit on the transaction as your policy. Now, this is just DOS policy, right? I'm not going to take any transactions that are below a certain fee. So you're willing to forego potentially child pays for a parent, anything like that, and presumably people know this, so they're not going to get through these fee filters if they're too low. But that's generally a pretty low number. And the reason it provides DOS protection is because some miner can take that transaction and confirm it, which means the fee has the potential of actually getting spent.

[06:05:48] And if you look at the pool of transactions we call the transaction pool, eventually it does tend to empty out. Even if it gets ridiculously full, eventually it does tend to empty out. So those fees all generally get paid over time. And you can have a graph of, like a subgraph of transactions, right? You can have 100 transactions that are all kind of connected, and there's one at the end that has a giant fee, but you can't take it unless you take all the others, kind of a child pays for a parent kind of thing, right?

[06:06:18] So you're not looking at one transaction at a time. You're looking at sets of transactions that are connected. And this is real computer science, graph processing. And this determining the set of transactions that I can fit into a block because of size, because of weight, because of SIGOP limits, because of lock times, and other consensus-based restrictions that have to do with the block context, you've got a complex problem to navigate your entire graph, and it changes every time a new block comes in, every time a new transaction comes in, the whole graph could change, right?

[06:06:54] So it's extremely computationally intensive to find the maximal fee. But what you really want to be doing as a miner is holding as many of those transactions as you can, because if you discard any one of them, you could be discarding unknown numbers of future, unknown amount of future fees, right? So you hold on to as many as you can without DOSing yourself or allowing somebody to DOS you. That's it. You want all of them, and you don't want to be DOSed. Well, a miner who's running a big-ass mine, what's the disk size limit they have?

[06:07:27] 1,000 terabytes? I don't…

[06:07:29] John Carvalho: So my question is, in your…you said we don't do…we don't have the concept of RBF and libbitcoin, but you did answer me earlier that you said the mempool full RBF was a good change. So my question is, how? Like, why does RBF…if what you're saying is accurate, why does RBF have to exist in the first place? It

[06:07:50] Eric Voskuil: Is accurate, and what you're citing is a narrow case, which I'm pointing out is in the more general case, doesn't require RBF policy, right? The idea of replace by fee is this…initially was this idea that if my transaction had a certain structure and I opted into it using this flag, that the node would then honor that voluntarily and say, I will take this one out and put this one in, right? That is a very narrow special case designed to kind of provide metadata for wallets and whoever, right, to know kind of what the person who's signing, what their intent is.

[06:08:31] Me, as a node developer who's supporting miners, right, I don't care what the person's intent is. I want the most valuable transaction I can get. So that's the general case, which is I see a higher fee, I'm taking it. I don't care if they opted in or opted out or what the inputs and outputs look like. As long as I can confirm this transaction and make more money than otherwise, I'm taking it. And that's the rational approach because that's ultimately what's going to happen. All miners are eventually going to do that.

[06:09:05] And if you don't build up infrastructure that expects that, then you're making a mistake. And RBF... Was a positive step in the right direction to say, we know this is going to happen, right? So that years ago, that RBF thing that was off by default, right? It's, you know, RBF policy you could opt into. I don't actually think it was on by default. Opt-in RBF was on by default. But they changed it, made it more general, right? Because they saw this coming. And I think that was a positive move.

[06:09:32] Ultimately, I don't agree with having a mempool at all. So there's no replacement happening. What happens in a transaction pool scenario is I get it. Let's just take a simple example. I get one transaction, goes onto my disk, right? Had the minimum fee. Had one Satoshi letter. And then I get another one that spends one of the same outputs that the previous one spent. Doesn't have to be even close to the same transaction. One can have like one output, the other one can have 1,000. Doesn't matter.

[06:09:57] But they are both spending one of the same outputs. So they're in conflict. So it's not a replacement scenario. I can't confirm both. And have a valid block because it's a double spend. But one could be confirmed in one block, and one could be confirmed in a competing block on another branch, right? They're perfectly valid independently. And some miner might mine this one, and some other miner might mine this one. I want to be able to build on those. And I want to have the transactions already validated and on my disk.

[06:10:27] There's a lot of reasons for me wanting as much information as I can as a miner, right? So the only problem comes in the implementation of this with respect to DOS. If I take that first transaction, and it's got x for a fee, which means that the person who submitted it is willing to sacrifice x if it gets confirmed. And it is confirmable. That means that if I get a lot of these, right, they're sacrificing it off. They're paying for the space on my disk. That's the way I think of it, right?

[06:10:59] So if my disk is filling up, I'm going to raise that level. And there's going to be fewer and fewer of those. And that's where I'm going to reach some equilibrium where I'm OK with what I've got. And that might change over time. I may have some cheap ones, and later, they might have to get more expensive. Who knows? Because maybe the price is fluctuating. Then I get another transaction, which conflicts. B conflicts with A. A had fee x. What if B has fee x? Then what happens?

[06:11:26] Well, if A and B both have fee x and they conflict, only one can ever be confirmed in the end, right? Even with two independent blocks, one branch is going to get orphaned, and only one will get confirmed, which means whoever sent me the second one or the first one, right? I don't know. Whoever sent one of these is not paying for two. They're paying for one. They've only sacrificed 1x fees. But they've sent me two transactions. And they could send me 2 million transactions with x, and they've still only spent 1x into the fee.

[06:11:57] So again, it becomes free for them to DOS me. So the way this is not replaced by fee, this is DOS protection. If I take in a transaction, I've already taken it, it's got x. And then I see another one comes along, it conflicts, and it's got 2x. And we'll assume this is a rate, so it's per byte, right? So it's proportional. I now can mine. I've got two transactions I can take. And my minimum fee rate was x, x per byte, right? I've already got that.

[06:12:32] But I've got a 2x that comes in, and they're the same size transaction. So if I take them both, what's my fee rate I've taken? My fee rate is 2x. I'm sorry, my fee rate is 2x over 2, right? It's x. So it satisfies my fee rate. I'm DOS protected. If I get another one that comes in, maybe it was the very first one, and maybe it's 1x. I'm not taking that. It doesn't satisfy my fee rate. I add that, I've got three of these same size transactions I'm putting on my disk, but I've only got 2.5x, which doesn't turn into, it's not 3.

[06:13:03] It's not satisfying my fee rate, which is x per one of those transactions. So I don't take that one, right? I might have taken it initially, but then I might not have taken the later ones because they haven't raised the fee rate enough. So that's the logic for protecting yourself in a way that allows you to take as many transactions as possible. They satisfy block confirmability in the presumed next block, and they satisfy DOS protection for fee rate, and that's it. There's no other reason to care.

[06:13:38] John Carvalho: So are you saying that basically, on one hand, you agree that opt-in RBF itself was pointless, but full mempool RBF kind of replaced that with a different policy concept that is sensible?

[06:13:57] Eric Voskuil: Neither of them were pointless, but none of them went far

[06:14:00] John Carvalho: Enough. So far enough would be doing it the way libbitcoin does it?

[06:14:07] Eric Voskuil: Yeah, from the very start I said I'm never going to implement opt-in RBF, and I'm never going to implement RBF, whatever they call it, which is I'm taking anything that raises my fee, raises my possible fee. I guess the

[06:14:20] John Carvalho: Gaslighting part of it for me was that we were using Bitcoin this way, and then Core stopped us using Bitcoin that way, and then the arguments were all revolving around opt-in RBF, that they knew what was best, etc. And so in the end, it's just like, well, if you're going to support something that flags intent for a transaction, why don't we just map all of the intents and say, okay, I want to have a flag for first seen, I want to have a flag for replace, I want to have a flag for...

[06:14:54] Eric Voskuil: None of those matter, that's why we don't do policy.

[06:14:56] John Carvalho: Delete after two days, right, because none of them are enforceable.

[06:15:00] Eric Voskuil: But my answer to you is, don't use Core, use something else. And you're like, well, everybody else is using it. Well, that's not Core's problem. Well, is libbitcoin

[06:15:09] John Carvalho: Usable for production for a merchant?

[06:15:11] Eric Voskuil: Bitcoin Core does not control what people do. They make the software. But

[06:15:15] John Carvalho: I just asked the question, is libbitcoin today, would you recommend it for production for a merchant? Right now,

[06:15:20] Eric Voskuil: No, it's not ready. But I am practicing what I preach. I'm not bitching about Bitcoin Core, not taking out all their policy. I'm making a node that takes out all the policy. And you can put it in if you want, right? But my point is that they don't control things. People give them that power. And if you want...

[06:15:41] John Carvalho: Yeah, I don't have the capacity to replace Core.

[06:15:45] Eric Voskuil: But if you want to run a node that has this special policy in it, then you've got to get people to run it. And maybe you could do a Knots. You could take Bitcoin Core, fork it, make the change, as you suggested, and then get people to run it. It's not Core's fault that everybody runs it. It's the fact that there's no other viable software out there that compete with Core. Well,

[06:16:06] John Carvalho: And it's not really viable for me to fork Core just to make a policy change either. Right.

[06:16:11] Eric Voskuil: So you're not going to win that argument. It's just the way it is. The rules in Bitcoin are the consensus rules. That's it. The other stuff's not rules. People can do whatever they want. And I don't agree with a lot of the network protocol stuff they do. And I don't implement a lot of it. And some of it I wouldn't implement the way they implemented because I can make it compatible but not do what Bitcoin Core does. One

[06:16:37] John Carvalho: Final related annoying question, which is, I know that we've discussed this before, and I know that I've remained stubborn on some of these aspects. But what was I going to say? So you helped me remember to frame opt-in RBF as a policy of intent, right, flagging intent. And do you not think that in the abstract or in economics, however you want to look at it, zooming out, that miners obeying intent of users ultimately provides a more valuable system? No. Like in other words, if we had this way to flag intent for like five different things, first seen RBF, delete after one day, whatever, like we had all these intents, and miners did enforce them, you know, voluntarily, that they would not make more money?

[06:17:41] Eric Voskuil: No. All it means is that the person who doesn't enforce them is going to make more money. That's what it means.

[06:17:49] John Carvalho: In other words, I don't want to make the transaction unless I know that my intents will be delivered. And if my intents are not delivered, I won't make the transactions.

[06:18:00] Eric Voskuil: Fine. You know, presumably there's a premium one. The

[06:18:02] John Carvalho: Idea here is that I would make more transactions if I had intent capabilities.

[06:18:09] Eric Voskuil: Okay, you're talking, you're making a classic, what I consider a classic economics argument error in the argument, and that is socialized gain for individual expense. And that doesn't ever work, right? It's the basis of communism, right? You're socializing the game. Everybody's going to make more money if we do what this guy wants with this transaction. But in order to do that, I'm going to have to, I'm personally going

[06:18:35] John Carvalho: To- I mean, maybe you're right. Maybe it boils down to that. I'm not sure. But just to continue my thought process, it's more like if I try to use T-Mobile to make a phone call and it works, then I'm going to keep paying T-Mobile. But if it doesn't work, I'm going to stop paying T-Mobile. Or if I get SIM swapped, I'm going to stop using T-Mobile. And yes, this is a trusted service and not enforceable and all these things. But just as- I'm just saying as a concept, people providing a service reliably make more money than people that don't.

[06:19:11] Eric Voskuil: If T-Mobile promised to not let you get SIM swapped, but somebody kept SIM swapping you anyway, how would you feel about their service?

[06:19:18] John Carvalho: I just told you, I would stop using it. Right,

[06:19:21] Eric Voskuil: So it's going to happen. People are going to do what you don't want them to do, because they can do it. It is perfectly legal under the consensus rule, and they will make more money by doing it.

[06:19:30] John Carvalho: Yeah, first seen was enforced for 10 years or something.

[06:19:34] Eric Voskuil: Not enforced, it was never enforced. Ever. And there's no such thing as first seen.

[06:19:40] John Carvalho: Well, there was definitely a policy in the nodes for first seen. No,

[06:19:44] Eric Voskuil: A node can first see something, but the network does not have a first seen.

[06:19:48] John Carvalho: Yeah, yeah, no, there was first seen mempool policy. Right,

[06:19:53] Eric Voskuil: You know why there was first seen mempool policy?

[06:19:56] I'll tell you, I know absolutely why there was first seen mempool policy. It wasn't even in my name. It's the easiest thing to implement by far. What I'm talking about in terms of competing fee levels for different branches, not even just individual transactions, but graphs of transactions, that's hard to implement, right? And libbitcoin, as far as it goes, it's first seen, right? It puts it on the disk. There's no mempool. But if it sees a conflict on the disk, it tosses it out. It's exactly what it does.

[06:20:25] There's no policy, but it's the only way it can DOS protect itself. If it sees a conflict, it's not going to accept it.

[06:20:36] So the problem, I think what you're looking at is you've assumed that there was some intent to have a policy that was based on first seen. I absolutely don't believe that. I look at Satoshi's code, and I look at the way he did things, and I'm like, this was the most obvious, straightforward, simple way to deal with conflicts, right? Have I got a transaction that comes in? I've already got one that spends that out, but I'm just talking to the other one. Because I can't keep up with it.

[06:20:59] John Carvalho: Well,

[06:21:00] Eric Voskuil: It's because it was

[06:21:01] John Carvalho: For someone who's not, especially when I knew less about Bitcoin than I know now, it actually makes sense from a user perspective, too, why an engineer would do the same thing. In other words, oh, that makes sense. I wrote a check, and I already made a commitment, and now I can't

[06:21:16] Eric Voskuil: Make a new commitment.

[06:21:17] No, the opposite is true. To me, the opposite is clearly true. If I write a check, and I give it to somebody, and then another one shows up that spends to the same person for the same thing, the second one is the priority check. It means that something was wrong with the first one. It wasn't enough or whatever, right? That's what we're doing. It's not enough. So that is absolutely the opposite of what I would expect.

[06:21:40] John Carvalho: Well, but this is speculation. We don't actually know, right?

[06:21:43] Eric Voskuil: But no, from a rational standpoint, the last one you see is the one. Otherwise, transactions get stuck. The spend gets stuck. And that is a real and a significant problem. So that's why RBF came about, because they had implemented this first seen policy just by accident. It was like, I've already got that spent. How am I going to deal with this other one coming in? I don't want them both in my mempool because I'm generating blocks from my mempool. That's why I have it. And I don't want to generate a conflict. If I leave it in there, it's going to be a conflict.

[06:22:12] It's going to be very complex.

[06:22:13] John Carvalho: Why wasn't it just addressed with CPFP and generating an extra output with every transaction?

[06:22:24] Eric Voskuil: Wait, wait. CPFP is way beyond what Satoshi was doing. We're talking about, why would you implement, if you're making a very first implementation of this thing, and you're just trying to get transactions in that spend outputs and put them in blocks.

[06:22:36] John Carvalho: I'm starting from my starting point, not Satoshi's starting point.

[06:22:39] Eric Voskuil: Satoshi comes along. I wrote this from scratch more than once. And this is what you do. First thing you do is say, if I have the same transaction, you check the hash. I've got it. OK, I've already got it in my mempool. Now, we're going to put it on disk? Yeah, we check it. Do I have this one already? It's already there. Toss it. So that's the most obvious thing you do. But then you have one. Then you find out when you're doing your testing, you have two different hashes.

[06:23:03] But you've produced a conflict in your block. You've actually double spent. And you go, oh, shit. So how do you stop that? One of two things. Well, three things. You toss out, you see two things that are spending the same thing, which, by the way, is computationally costly across your entire pool to check every single thing spending the same output. You're basically looking for duplicate inputs between your transaction and every other transaction. So every input in the new transaction that shows up has to be compared with every input in every other transaction across potentially millions.

[06:23:33] So it's expensive. And you do that, and you find there's something already spending this. And you go, well, do I want the new one, or do I want the old one? Well, all I know is that they're spending the same input. They're spending the same output. But there might be different numbers of outputs in one versus the other. And I might have a whole trail of transactions that are following the one that's already in there. So if I take it out, I can maybe insert the other one in.

[06:24:00] But if it doesn't have the same outputs, now I've got to propagate that deletion across the entire graph. It's going to knock out all this shit on my graph. Now it gets costly, expensive, and complicated. So the obvious thing to do, the easiest thing to do when you're doing a first prototype implementation is say, if I have any conflict coming in on a transaction that's already in the pool, I don't take it. That's it. And eventually, somebody comes along and says, well, this sucks because we can't get our transactions confirmed that the fee rate gets too high.

[06:24:32] Nobody's mining these because they're too low. So let's see if we can bump the fee rate. Well, one way to do that is say, I think this is the way opt-in RBF works. If the transaction had the same inputs and the same outputs, it's basically the same transaction, but it increased the fee in comparison to one that we already have. Then I could do what I just described to you without any disruption in my graph. I could say, OK, it's the same transaction sans fee and maybe a flag.

[06:24:58] So I can just pop this one out and pop this one in. There's no disruption in my graph. The fee's gone up. It helps the miner. It helps the person trying to get the transaction confirmed. Great. That's what opt-in RBF was. And I think the opt-in, the flag that says this is an opt-in RBF, was the indicator to the node that it should check for this scenario. So it was an optimization for the node as well. Say, I'm not even going to check for this unless you set this flag, not as a way to make it.

[06:25:25] John Carvalho: It's the reason I think there was more complexity added to RBF at some point than that.

[06:25:28] Eric Voskuil: I think that was the initial cut. There was a BIP on it. I never implemented it, so I could be guessing. But what came later was as mempool implementations got more and more complex, they started dealing with child pays for parent, not just for an individual transaction, but for a whole subgraph. And now you've got Pieter Wuille's out there doing this distributed mempool thing, which is basically what I'm talking about. We've been working. We've had this design for years. And we've done an implementation of it. It hasn't shipped yet.

[06:26:03] But it's graph processing over a graph of inputs to outputs where you can have in the pool any number of conflicts. I can have a whole pool of transactions that form all these independent graphs. Well, independent in some way. They all connect somehow. And they conflict like this subgraph conflicts with this subgraph. There's something in here that's going to conflict with something in here, which means I can't take both of these. Those are conflicting. But I'm still going to hold them all in memory. And then maybe something comes in and it's a child of this, and it's a huge fee.

[06:26:37] And I can take that whole thing because it outweighs this thing. And that's extremely complex processing. That's real computer science. To do it naively, it's not too hard. But to do it performantly, it's not possible, actually. You have to turn it into heuristic. You have to guess because it's way too computationally infeasible, it's a traveling salesman problem on steroids. So the reason it didn't get done was because it was hard to implement reliably. And he was building a prototype. But very soon after that, we got RBF.

[06:27:11] Then we got the opt-in RBF, which improved upon it. And then we got the other RBF, which generalized it even further. And they're still struggling with overflowing mempool. Which ones are we going to kick out? Deciding which transaction to kick out of the mempool when another one comes in? Oh my god, that's a real problem. That's a complex problem. It's not as simple as it might seem. So the approach we take is memory is the most expensive resource on the machine. And disk is the cheapest resource on the machine.

[06:27:40] So as long as it satisfies fee policy, we put it on the disk. The problem is bigger than that because having it on the disk serves a couple purposes. But it's not sufficient to do mining. Having conflicting transactions on the disk is fine because they're not in blocks. They're not confirmed. So we put them on the same. We have one table that holds all transactions. It doesn't matter if it's confirmed, not confirmed. They're associated by headers. And the headers get confirmed. And that's what makes it a chain.

[06:28:11] But if we take transactions and put them on disk, then when a compact block header comes in and says, we've mined all these transactions, we go, yep, we got that one, that one, that one, that one, that one. And they've all been validated already in some context. And so all we do is make sure they're there and check to see if the context is still sufficient. It's not going to necessarily be the same. It won't be the same because median time past won't be the same. But we can look at the context, and we can say, is it sufficient for these not to have to be revalidated again?

[06:28:45] And if that's the case, we're done. We have to validate a single signature, Coinbase, no signatures. And so we bring the Coinbase in, we lock in. So in order to do that, we need certain metadata. We need to know how big all the transactions are that just came in. All we got is hashes. So we need to know how many SIGOPS are in all the transactions. We need to know the lock time issues. We need to know total weight, total size. So we need to know double spends, right?

[06:29:17] John Carvalho: It sounds like you would avoid a lot of headaches if you just said first seen.

[06:29:21] Eric Voskuil: Nope. You wouldn't avoid them at all. You'd just go out of business.

[06:29:26] John Carvalho: Well, not necessarily. I mean, you wouldn't be optimizing, but you'd still be taking fees.

[06:29:33] Eric Voskuil: That's how you go out of business. It's not optimizing your income, which is strictly fees. So yeah, that's not a rational approach. No,

[06:29:42] John Carvalho: You wouldn't be hardcore optimizing. You would still be optimizing by the size of the fees of the transactions you did keep, right?

[06:29:51] Eric Voskuil: Okay. Well, I tell you what.

[06:29:52] John Carvalho: And if the mempool is overflowing, how much cream are we talking about exactly? I'll

[06:29:57] Eric Voskuil: Tell you what. If all the miners want to mine on first seen and that's it, I'm all for it. If you can convince all the miners to do that, I'm going to put every last red cent I have [unclear: into mining on my own node].

[06:30:14] John Carvalho: I'm partially teasing. I do understand the nuances and I have actually learned a few more nuances as you spoke. So I appreciate it. But yeah, it's hard for me not to think that as you describe basically the impossibility of optimization. And I'm thinking, okay, well, impossible.

[06:30:31] Eric Voskuil: It can't be fully. There's no way to fully optimize it. In other words, there's not enough time

[06:30:35] John Carvalho: When I think about how you have all these like graphs of transactions that are codependent and you and your hopes of actually comparing them become like infinite.

[06:30:44] Eric Voskuil: It's like you're like, this is too hard.

[06:30:47] Let's just not do this.

[06:30:50] John Carvalho: Right. Like it just seems like it seems like it's so hard that you might be optimizing to make one cent. It's like, you know, you know, like,

[06:30:56] Eric Voskuil: You know, we make, we make mobile phones, but, you know, [unclear: the touchscreen].

[06:31:01] John Carvalho: You also back here in the computational costs. Do you compare the the potential computational costs to the fee difference? Like,

[06:31:10] Eric Voskuil: Yeah, you do. Yeah, absolutely. The computational cost. I mean, the biggest the big computational cost is time, because the more time you spend not. When

[06:31:19] John Carvalho: You're analyzing the graph, are you factoring cost of analyzing the graph?

[06:31:25] Eric Voskuil: You mean the electricity cost of running the CPU to. Sure. What

[06:31:29] John Carvalho: If the difference is just 10 sats or something? You're going to run all that.

[06:31:33] Eric Voskuil: Then you then. So there's always going to be a limit on your on your graph processing where you have to arbitrarily cut it off at some point. You just tune it down. You don't want you know, you don't think it's profitable. But but the the the idea that you're not going to attempt to optimize profit because it's too complex to the

[06:31:50] John Carvalho: Spectrum. Right. I didn't. That wasn't quite what I said. What I said was I'm not going to go that far with optimize. OK,

[06:31:56] Eric Voskuil: Well, you're saying the same thing. You're saying I'm not going to optimize to my fullest ability. Right. The cost and the cost is inclusive of everything. Right.

[06:32:05] John Carvalho: I'm not going to do that.

[06:32:07] My girlfriend's always trying to do things that will save us like 25 cents. And I'm like, I understand the idea of costing us so much just by worrying about telling me it's a cost. But

[06:32:16] Eric Voskuil: Realize that I'm doing this for free. I'm writing the software for these miners for free. They're not paying shit for this. So that's the biggest cost. I've worked on this for years. Right. And when they can plug it in and run it right. And the code's all written and it just sits there. It uses, you know, the trivial amount of electricity. It's not fucking hashing. Right. So if I was if I was a miner and I could invest, you know, a certain amount in hash rate and a certain amount in optimizing what I'm hashing for, I would put a significant amount of money towards optimizing what I'm hashing on.

[06:32:53] Because if I'm spending all that time hashing, presumably the only thing I'm getting out of it is the money that I put into the blocks, which is what, suboptimal? Why would I do that? I want. I mean, with

[06:33:07] John Carvalho: Libbitcoin, since you save everything, you could do some post analysis to see how much optimization really gained you. Right.

[06:33:14] Eric Voskuil: You could. It would be expensive to find the optimal. Right. Like to find.

[06:33:19] John Carvalho: Well, I just mean comparing what you did to first seen, for example, you'd be able to do something like that.

[06:33:27] Eric Voskuil: It's not limited to first seen. You still have to deal with which ones you take of the ones you saw.

[06:33:33] John Carvalho: Comparing one policy to another policy.

[06:33:36] Eric Voskuil: You'd have to store the time or the order in which they were retrieved. And then you'd have to, you know, you'd have to, you know, compute the computational cost and all that shit. And I can't imagine anybody would ever do that. What you would do is you would look at your profit ratio compared to people that aren't doing it. And that's how you would determine whether you're winning or losing that game.

[06:34:02] And, you know, if you if you can't come up like first. First of all, I mean, what do we typically see miners do when a new block comes in? They mine an empty block. Why? Because the fastest block they can find. It's valid. They have an empty block already to go. As soon as that one comes in, boom, they're mining. So they're not wasting their hash rate. And now would you mine an empty block if you have if there's no block reward, if there's no subsidy? I don't know.

[06:34:31] Probably not. Because even even if the subsidy gets pretty low, would you mine an empty block? Well, no, it's not worth the hash rate. The probability says you're not going to. I don't know. But there's some point in there where that's not even feasible. So what are you doing? You know, you're you're you're there's a shift from just because the mentality of taking like, you know, whatever comes in for fees is based on this idea of the subsidy being the overwhelming part of the reward. Subsidy is going to zero.

[06:34:57] So the fees are going to be the only part of the reward. And if if people aren't optimizing for fees inclusive of all their costs, right, then they're going to go out of business. They're not going to be the most efficient miners. And mining is a zero sum game. So I'm you know, all along here, we've been we've been working towards the the game that makes miners most efficient. Now, let me put this in perspective of security and, you know, kind of the cypherpunk mentality. The threat, the state, right, which can mine centrally in one location has a significant advantage because it can seize mines and mine in one physical location, which is much more efficient than mining in a distributed fashion because of latency.

[06:35:41] Now, people say, well, there's no more. There's no latency because we have compact blocks, whatever. That's bullshit. There's no latency because mining is heavily centralized and or there's less. You know, there's less orphans seen because mining is heavily centralized in the way you measure latency kind of by how many orphans you're seeing. But as people start distributing into the woods and running their little mines to compete with the state to capture those excess fees. Right. Then they're going to be mining at an inefficiency. And if the state is, say, taking any fee they can get and putting money into optimizing and you're not, you're at a disadvantage or a double disadvantage.

[06:36:17] But then consider the fact that the way censorship resistance works is when a when a transaction is censored. Right. The state censoring there. They're doing a majority hash power censorship thing. And they don't take your transaction because, you know, you're you're living out in the jungles of Myanmar and using your using your money to buy those guns. And your transaction is not getting confirmed. So what do you do? You increase your fee. That's how you do it. And it still doesn't become you don't even know you're being censored, but you increase your fee.

[06:36:49] It didn't go through. I'm trying to make my payment. Didn't go through increase my fee. And all those fees that are piling up that the state's not taking, the censors not taking because they're censoring you. Right. That becomes a cost to them. But if everybody just mines on the first one they saw, no cost to the state. It's that the fee is not rising. That fee has to rise based on subsequent transactions until the censor, until there's enough potential money sitting there for somebody to come in and violate the censorship protocol and overpower the censor with majority hash power.

[06:37:23] So it's a primary security issue as well. You have to take the most profitable transactions. And that's not going to be the first one you saw.

[06:37:33] John Carvalho: I understand. I feel like there's some weakness there.

[06:37:41] If the state is already so large that it's in that position and I'm just playing devil's advocate.

[06:37:52] Eric Voskuil: If you don't play devil's advocate, the state's winning the hash power battle and no amount of fee increase by people is going to be that they're willing to pay is going to be able to overpower them. It's moot. First seen doesn't matter. Nothing's getting through. And your zero-conf isn't going to work. Well,

[06:38:09] John Carvalho: I guess maybe that was kind of what I was going to say. I was just also going to add another part where all of the other miners that aren't the state would still have my first transaction that was censored by the state. So as long as they were mining a block, they would be able to include my transaction if they

[06:38:29] Eric Voskuil: Wanted to. They're going to be doing something now that's illegal because your transaction is illegal. But if

[06:38:37] John Carvalho: Non-state miners not mining transactions because they're illegal is the security model, that's not a security model. It is a security model.

[06:38:45] Eric Voskuil: Hear me out. The state comes and says these transactions are money laundering. In other words, let's take a very practical example.

[06:38:56] John Carvalho: Very specific. OFAC. This transaction is my OFAC address. I'm

[06:39:00] Eric Voskuil: Going to go harder than that. I'm going to say there is a global consortium of states which already exists that protect their money. It's called the IMF. And they've come up with a policy that says, a law, a regulation that says there will be no transactions in our financial system unless we have signed them. Which is already the case. There are no transactions that occur in the legacy financial system that are not, in one way or another, approved. So maybe they decide, the way we're going to do this with Bitcoin is if a miner mines a transaction that has not received a stamp of approval, which means a digital signature attached to it by us, it is a money laundering transaction, by definition.

[06:39:47] So any transaction that anybody else implements doesn't get through. And how do you get that signature? The way you get that signature is you walk down to your bank, and you say, I want to send this Western Union. Same old bullshit. Same stuff that already exists. And you show your ID, and you pay your demurrage. There's your inflation right there. The demurrage per transaction. And you're totally unmasked, and you've paid your inflation fee, and now you can get your transaction through. And the way they're enforcing this is just a simple soft fork.

[06:40:19] They do a soft fork enforcement, and they say any miner that mines these transactions better be mining only signed transactions. And by the way, they better sign the block themselves so we know who mined these transactions, and so we can verify all that shit. If somebody mines a block that has some unauthorized transactions in it, or they're an unauthorized miner, now they're in some shit. And so that's where you are. You're out there in Myanmar, and you want to buy your ghost guns, and you've got your transaction.

[06:40:45] And you're not going to do any of that bullshit. You're just going to submit your transaction to the peer-to-peer network and hope that somebody mines it. And you pay your fee, not knowing maybe that this shit's even happening, and your transaction doesn't go through. Now the state's not taking it. Nobody else is taking it. And what you're arguing is that people will just take it anyway. And what I'm telling you is that no, it's not worth it for them.

[06:41:07] John Carvalho: No, what I'm arguing is your assumption is that Bitcoin has already been compromised.

[06:41:12] Eric Voskuil: No, there's no already compromised. This was always going to be happening. You should assume that this is how Bitcoin works. This is how it's designed to work, so this better be how it works. It's designed to deal with this specific situation. This is the only way Bitcoin is censorship-resistant. So it's designed to deal with the fact that the state is doing what I just described, or something analogous to that. And there are miners out there who are not mining because it's not worth it. They're going to lose money because the state has a centralization advantage.

[06:41:44] Not just one, but all the big mines, which are kind of co-located, have no regulatory risk and have centralized hashrate, which means they have a latency advantage, and they have a, what do you call it, the other advantage, frequency of payment. They have both advantages, right, because they're big and they have low latency. So they're already mining at an advantage, so you're losing money. And you're going to shut down your mine. You shut down your mine, you're losing money. But you're monitoring the mempool, the transaction pool, as I would call it, and you see fees on all these millions of transactions are going up, up, up.

[06:42:24] Why are they going up? Because they're not getting confirmed. It's just what happens, right? People who they're replaced by a fee, they're just boom, boom, or they're child-bumping them or something, right? And then they're going up and they're going up, and you're like, holy shit, look at that. Look, I could mine one block and one. I just turn on my mines, I grab all those transactions, I submit the block, right, and everybody else is doing it too. And all of a sudden, we're mining at a higher hashrate than the state because there's money there to pay for it.

[06:42:52] The only way the state overcomes that is to subsidize their mines. They can't take the higher fees. They're operating a lower success for their given hashrate. So they have to subsidize at the, it's basically the way, if you take out the latency differences and that, it comes down to the increment in fees that black market transactions are paying, the difference between the fee level that's getting mined by the state and the fee level that people are willing to pay, that difference is the amount that they will have to subsidize their mining.

[06:43:25] That doesn't sound like a lot, and it may not be enough, but that's the only thing that provides censorship resistance is people willing to pay more for their transactions. And if these are big deal transactions- It

[06:43:35] John Carvalho: Feels a little insecure.

[06:43:38] Eric Voskuil: Well, that's how Bitcoin works. I hate to frickin' break it to you. There's nothing else protecting it.

[06:43:42] John Carvalho: It sounds like inevitably, Bitcoin is going to be captured. That's what it sounds like.

[06:43:47] Eric Voskuil: Well, it'll be majority hash power enforced. Yes,

[06:43:51] John Carvalho: That is probably going to happen. Because centralization is an efficiency, so miners will always trend to centralization, which will always trend them to capture.

[06:43:59] Eric Voskuil: Why do we work on, and core development, two things we work on, right? We work on making it, balancing out those mining inefficiencies, right? So P2Pool, not very efficient, but the idea, right, is that you can do it anonymously, but it's not efficient, right? So we've got people that work on trying to limit, at least, if not eliminate, the advantage to centralized mining, the technical advantage to centralized mining. I'm not even talking about regulatory or whatever, right? So that-

[06:44:33] John Carvalho: I don't see how that could be eliminated.

[06:44:36] Eric Voskuil: Okay. Well, but that's what people are working on, right? That's what P2Pool is all about. So Braidpool guys and others work on this idea of reducing the advantage to centralized mining. And the other problem with being able to mine or transact when it's not allowed is privacy. So other people work on privacy enhancements to Bitcoin. And part of that, part of privacy is being able to operate at very low scale, right? I mean, the guy peddling corner weed doesn't come along with a semi full of weed and set up shop on the corner.

[06:45:14] He operates at very small scale, and that's how he hides. He's doing a high volume business. He's going to be highlighted. So the idea of decentralization is not enough to provide security. Decentralization exists to provide the ability to operate at small scale and hide. So without identity, right, and with an equal advantage. You're not going to disadvantage the state because you don't know who it is, but you want everybody to have an equal advantage as much as possible. But the censor has an inherent disadvantage as soon as he starts censoring.

[06:45:48] That's why generally, unless it's a state attack, there's no reason to censor and there's no advantage to it, right? You just take the most valuable transactions you can. Otherwise, you're just losing money. So there really is no threat apart from the state which wants to censor so they can preserve the purchasing power of its own money, including the ability to tax through the money, et cetera. So that's why the state is kind of designated as the threat, because they're the only ones that have the incentive to do that, right, to censor.

[06:46:15] And the only thing that could possibly counter that censor, aside from voting, which is the system we already have, which doesn't work, right, but it doesn't provide that feature because people don't really want it.

[06:46:29] John Carvalho: I'm concerned that the error mode, in other words, once the state is suppressing or censoring, that the situation you describe where there's millions of transactions that would make me set up for life if only I started mining again, sounds kind of unlikely to me. I feel like once I've been cornered out of mining, I'm probably not going to be watching any mempool. But why do you work with Bitcoin? Because maybe none of this will happen until I'm dead.

[06:47:01] Eric Voskuil: Right, but I don't really care that much. I mean, the reason I work on it is because I want people to have permissionless money.

[06:47:09] John Carvalho: No, no, I want that, too. But what I'm saying is you made a huge leap, as in just because Bitcoin is providing this service to us now, but what you described does sound somewhat inevitable. Bitcoin

[06:47:23] Eric Voskuil: Is being allowed. It's permissioned right now. It's not providing permissionless money. It hasn't even been tested. I mean, it surely likely wouldn't have been shut down a long time ago if it was totally centralized, like Liberty Reserve, for example. However, it has not been tested, and I think it's really silly if anybody wants to say, Oh, you know, we're doing great. Like, look at, you know, we're censorship. No, we're not censorship-resisting, because I just showed you.

[06:47:54] John Carvalho: I wasn't even finished. I was going to describe like, okay, like, we have miners now that have to comply with OFAC. And some say that they do, some say they don't. Do they not

[06:48:05] Eric Voskuil: Mine on blocks that are accepting censored transactions? I think

[06:48:11] John Carvalho: Only because the state hasn't made that nuance a requirement.

[06:48:17] Eric Voskuil: They don't have enough, they don't have enough hash power. They don't. So what would happen is if they impose that now, it would likely just put those miners out of business, because they would be, they would be orphaning a lot of blocks. And so once they get to majority hash power under control, then there would be no problem.

[06:48:34] John Carvalho: Because we have this issue with Lightning as well and other, like, Bitcoin stuff. Like, my lawyers are very specific about what we can and can't do as an LSP and, you know, in this kind of thing. Money transmitter. Right, right. Like, in other words, if you want to do this, this and this, you can, but you're going to have to get licensed and you're going to have to do it now. Yeah, you can get licensed. And it's like, okay, then why, then I guess Lightning's kind of fucked too eventually. So I

[06:49:03] Eric Voskuil: Ask people, why do they work on this stuff? Right? What I explained to you is not controversial. I think you accept what I told you is a reasonable security model, and, you know, it very possibly could happen. So I ask, why work on it? Like, you can't prove. That the censorship—

[06:49:25] John Carvalho: I thought we were all working on it to get rich.

[06:49:27] Eric Voskuil: Nope. So you can't prove that the censorship—but that is telling, right? Like, it's a kind of a rhetorical question. Why are you working on it again, if you don't believe this stuff? But if the censorship aspect, you know, if censorship-resistant money is what it's all about, and that's what gives it its value proposition. And I just showed you how fairly trivially it could be censored. The question is, well, what are we doing? Right? You can't prove that the state will be able to generate enough tax revenue to pay the subsidy to overpower people that, you know, are willing to pay higher fees for their transactions.

[06:50:03] But you also can't prove the opposite, which you pointed out, and I agree with. You can't prove that people are going to pay enough to incent those miners to break the law, to mine the transactions, and continue to do so, so they don't get—the branch doesn't get completely orphaned off. But it's possible. And so I work on it. That's right there in my book. I think it's chapter one. Right.

[06:50:23] John Carvalho: So, like, neither of us can predict the future, which is another reason to keep working on it. In other words, you can't predict either of those outcomes for sure. There might be a third outcome, you know, like—

[06:50:35] Eric Voskuil: We believe it's possible, and we think it's worthwhile. We can't prove it will happen one way or the other, but at least we are honest about how it works. What I get fed up with is people just completely denying how it works, primarily because they don't give a shit about this. What they care about is their NGU until the state takes it over and it becomes PayPal. That's it. And I don't care...

[06:50:58] John Carvalho: And honestly, it seems a lot like NGU is mostly turning into, you know, deference to the state. It's just saying, oh, the state, come on in. Take everything because you're going to make me money.

[06:51:10] Eric Voskuil: If you're doing institutional white market Bitcoin, you have no choice. That's why I do not work on anything that's institutional white market Bitcoin. I mean, they can use my node, right, but I don't design for that because it has no security. There is no security in the white market. If you're not willing to say no to the rules, right, you have no resistance whatsoever. You're not part of the security model. So I laid this right out in my book. Nobody in the white market who is unwilling to act without permission is part of the security model.

[06:51:46] They are a no op in the security model, which means Saylor, which means all the ETFs, which means Coinbase, which means all the big miners. They do not count in the security model. Now people come and say, well, we can vote for it. That's the status quo. We already could vote for good dollars.

[06:52:06] John Carvalho: You may want to look at this if you haven't heard of it, but France is already making things worse. Any transaction involving anonymized cryptocurrency or a mixing service will be considered money laundering by default. This is a presumption. So they're reversing the burden of proof. I

[06:52:22] Eric Voskuil: Have a good friend that runs an exchange, and I was like, no, European. This is coming for you. This is years ago. I'm like, that's not a sustainable business model running an exchange. You're going to be part of the problem soon enough. And

[06:52:40] John Carvalho: Now they want to bring exchanges to Lightning by bringing tokens to Lightning with the edge nodes.

[06:52:45] Eric Voskuil: All this shit happening in the white market with Lightning, I don't care. To me, it's not even part of Bitcoin. This is why I don't get involved with most discussions that go on about, OK, Adam wants to talk about the number and this thing. And I'm like, OK, fine, fine. But you're not relevant anymore if you're not working on black market money. And because there is no value proposition, there is no reason for it, it's just a casino. And I don't care about that. Why would I spend my life working on that?

[06:53:13] I could just go to Vegas and roll the dice. So I don't know. The reason I talk about it, the reason I get on these podcasts and anybody asks me is because there's some people that just don't understand this. A lot of people don't understand it. The class of yesterday, they show up, and they've heard nothing but cheerleading. And then I come along, or black comes along, and we tell them, hey, that's not what you're here for.

[06:53:41] And some people love it when the light comes on. But I agree with you, there's no guarantee it's going to survive. But I tend to think of it this way. Bitcoin can be completely subverted through majority hash power attack. They can impose demurrage, which without even changing any rules, impose demurrage, impose complete transparency in all transactions. And basically, all the value prop is gone. It becomes PayPal. And that can happen, and it could be completely dead. But it's going to keep coming back, because when the hash power attack goes away, then it comes back.

[06:54:18] So I kind of prefer to work on the software and the tools to allow that to happen. So for the rest of humanity, the span of life on Earth and maybe Mars, it's always going to be there. And it's kind of like gold in the past. When society comes apart in the past, money dies. There you go. You didn't quote it.

[06:54:46] John Carvalho: I'll be putting these as merchandise soon in a store, but we made this black market money. You didn't put

[06:54:52] Eric Voskuil: The little quote, "Eric Voskuil," at the bottom.

[06:54:54] John Carvalho: Oh, that's what you want? That's my quote.

[06:54:59] Eric Voskuil: That's a failure to attribute, you know.

[06:55:02] John Carvalho: Did you actually really [unclear: coin that]?

[06:55:07] 'Cause I feel like it's just been a thing. If

[06:55:12] Eric Voskuil: Anybody said it before me, it was probably Amir. I don't know. But it's kind of a mantra. I'll send

[06:55:22] John Carvalho: You a free shirt.

[06:55:23] Eric Voskuil: OK, let's consider it paid. But I think, you know, it's going to as long as the software is still there and people know this thing exists, then it will still be possible to keep coming back forever throughout all the unlimited number of years in the future. It's always there. And maybe something better will come along. Maybe someone will solve some of these problems. We may

[06:55:47] John Carvalho: Find that there's a level to stay under. You know what I mean? In other words, Bitcoin can be so big and then it gets captured and then it comes out.

[06:55:59] Eric Voskuil: I agree. And you're hitting on a very relevant question. So what are we doing with scaling again? What are we trying to do? Well, we're trying

[06:56:08] John Carvalho: To maximize the amount of people that can use black market money.

[06:56:11] Eric Voskuil: But that's not what we're really doing. What most people are doing is trying to maximize the amount of people that can use white market Bitcoin.

[06:56:21] And in terms of black market Bitcoin, I think we're doing pretty good right now in terms of, like, I don't know anybody that's having a problem getting their Bitcoin transaction through on L1 ever. So, okay, I think we're all right right now. And my priority is not to make a very complex system that tends to be centralized and that nobody should actually run in the jungle and tell them, this is what you got to do because we're scaling. No, I'm just going to use whatever, and I'm going to transfer my money.

[06:56:55] So I don't know. I tend to think we can build simpler, performant, easy money that satisfies the requirements. It's just that we have a requirements problem. Really, the biggest problem Bitcoin has right now is a requirements problem. There's a requirements bug, and it's white market. Just take every single white market scenario and just fucking toss it. Now you've got the requirements right. And that changes everything, where all the money goes, right? Who's giving the money?

[06:57:32] John Carvalho: Well, yeah, and this is, I don't know how often you listen to any of my interviews or tweets, but this has been a very common theme for me, like pointing out that the entire Lightning Network is entirely subsidized, that these scaling methods are all things nobody will actually tolerate as far as complex normal users. These are all performances, and what I point out is that there's a budget for speculative development. And if that budget is consumed by things that are a waste of time, then we are all wasting time and we're not making progress.

[06:58:08] Whereas if we can better understand what things to work on, then that budget is put to good use for real humans. And for me, like, whether it's black market, like I avoid the black market money term in a lot of situations just because people think black market means evil. Because the government said, yeah, right, criminal, evil, same. But when you use it, you mean something very specific. I mean,

[06:58:34] Eric Voskuil: Free market, right? And free market is the market that doesn't get [unclear: permission].

[06:58:38] John Carvalho: Yeah, the rules that weren't made by the government. And so for me, like, I'm trying to optimize people being able to do direct commerce with each other. In other words, without middlemen being able to stick their fingers in the pot and mess everything up with regulations with, you know, whatever it may be.

[06:59:00] Eric Voskuil: I mean, I wouldn't have a problem with middlemen as long as they can't be used to take control of the system or their, you know, and it's all voluntary. Yeah,

[06:59:09] John Carvalho: I don't have an issue with like middlemen as a service. In other words, curation, sourcing, this kind of thing. Lending. I more mean the, what's the word, rent, you know?

[06:59:21] Eric Voskuil: Lending, right? Like where you have a facilitator, a bank that facilitates money's coming in, money's going out, right? That's a middleman, and people would say, oh, Bitcoin is like, oh, no, banks! You're not going to have lending, right? Anybody who's lending is essentially a bank, or investing, because investing is just lending.

[06:59:38] John Carvalho: I guess I would identify middlemen as points of censorship.

[06:59:41] Eric Voskuil: Right. Well, that's why when I said it, I said, like, as long as they're in this position where they can't be used to take control, right? Banks are, free market banks become a weakness, just like anything that kind of gets larger in the free market, right? State steps in and takes control. And the way they took control of banking in the US was through the Federal Reserve Act, which basically subsidized member banks. And so all the other banks went out of business. And so by giving free money, essentially interest-free loans to your member banks, because you control the printing press at the Treasury, you can put them out of business.

[07:00:19] So you can take control of the system because it's aggregated so much, right? And the same would happen if a bunch of miners have aggregated all the hash rate, then you take control of that. You've taken control of mining. Now, of course, the people who are actually doing the hashing, they can go somewhere else, but then they're operating at a disadvantage because they're operating at smaller scale. And that's the issue that we have to deal with. And typically, what happens now is everybody gravitates towards the most profitable mining pool.

[07:00:48] And even though they can leave it, if it starts censoring, the question is, why would they if they're making more money? So again, it comes back down to individualized cost and socialized gain. And that's not a reasonable set of financial incentives. So things like, this is why I come out against things like, what's the newer mining protocol?

[07:01:22] Vlad Costea: Ocean?

[07:01:24] Eric Voskuil: No... Stratum V2. Stratum V2 is an example that's right, where obviously the miner who controls the payout can control what blocks get mined, even if they don't select the blocks.

[07:01:37] They just not pay people and they will go out of business. So the argument that I pointed that out right off the bat, and this is another one of these things, it sells itself as security. It's not. It might be a nice engineering feature, but it's not security because it doesn't provide that benefit. And then the argument becomes miners can leave this miner, the miner is censoring, because they're not paying miners who are mining unauthorized blocks. And so they leave. But where do they go? They go to the next biggest miner who's doing the same thing.

[07:02:17] All the big miners are doing the same thing. So where do they go? They all go the small mining. So really, has it solved the problem? No. They've had to go off and hide. People will be able to tell whether large-scale mining is state censoring. That's not really a mystery. So the question is, what's it doing? It's another one of these false sense of security engineering solutions, like Dandelion or whatever. It's like, you know,

[07:02:44] John Carvalho: We're- Do you think Braidpool is a solution or improvement?

[07:02:48] Eric Voskuil: You know, I was there when Braidpool was announced at Scaling Bitcoin Hong Kong. And that's where I went up to Bob. And I was really excited. I was like, this is, you know, I was pretty new. And I remember thinking like, you know, if this does what you're saying it can do and what it seems like it can do, it could be really important because this is one of the most important issues in Bitcoin. But I've followed it. And Bob's a friend. And Kulpreet, who's doing the coding on it, you know, he's a Bitcoin guy.

[07:03:15] And he's one of our-

[07:03:17] John Carvalho: We met at a couple of conferences and became friends over cryptoeconomics. Kulpreet? Yeah,

[07:03:23] Eric Voskuil: Yeah. Yeah, he's great. And he's like a computer science PhD. He's been kind of a part-time contributor for a long time. And I have him to thank for helping me [unclear: dislodge] In my brain how we could solve some of the problems that led to where we are now. So both of them are great. But I've participated tangentially in Braidpool and other related things and kind of like working group level. And you know, I'm not entirely convinced that there is a solution. But if anybody's getting closer to a solution, it's them because they're working on the right problem.

[07:04:00] And the other example that was kind of like Stratum V2 was FIBRE. It's also one of Matt's things. FIBRE, similarly naive in its attempt to provide a security benefit. I think these things, like FIBRE and Stratum V2 as examples are an example of doing for the right reasons the thing that doesn't really accomplish the objective. Same with Dandelion, same thing, right? There's a lot of these things that, like, they just don't get enough to move the bar. But the problem is that they advertise themselves as having done so, which draws money into them and away from other solutions. So Braidpool didn't get funded for like, I don't know, 10 years or 90. It just got funded recently. It was years. I think six years working on this one source of funding. Long time. And it's finally got some funding. And so they're finally starting to do some work. But all this other stuff, which was from the beginning obviously not going to solve this problem.

[07:04:57] And so FIBRE was this idea of reducing latency. And so if it's P2P protocol, and everything moves faster, and every miner sees everything faster than they would have otherwise, it's great. It's positive for security. So that's what compact blocks does. Compact blocks reduces latency, reduces the amount of orphaning. If there's a constant amount of orphaning across the whole system, it's not a cost to anybody because it's a zero-sum game. Everybody's paying the same profit. But it's a disproportionate level of orphaning. In other words, smaller miners create more orphans than larger miners because they're farther apart from each other, and therefore, they don't see blocks as soon.

[07:05:34] So it's a problem. Reduce latency, you can reduce that. But proportionally, you're probably not really reducing it anyway. So net-net, it's about the same. But with compact blocks, we have a P2P protocol, which dramatically reduces latency. But do miners rely on that? No, they spy mine. All the big miners connect to each other's pools, and they see the blocks as soon as they come out of a competing pool, which is as fast as it's going to get. FIBRE comes along, and it's like, we're going to do better than compact blocks in this FIBRE relay.

[07:06:07] And the way FIBRE became faster, apart from all the miners joining this public network, which really didn't do anything, was to create a private relay network. So there were two things. There was the protocol and the public aspect, and then there was a private network, which somebody, maybe Matt, managed because it had no security. It intentionally had no way to protect itself from being destroyed by spam. And so they basically had to sign up and join, or they had to be identified, and then they could be kicked off.

[07:06:44] Miners could be kicked off the system. That's how it was protected against. And the messages were put into very compact messages, so like one packet, you could send things out. So it was basically packet reduction and compression, very low latency, great, but centralized, totally centralized. The only way it could work was with a central authority. So that didn't do anything. And then the one that was not centralized was just P2P network. If it was worthwhile, it's basically just compact block. Put it in the protocol, great. But people are spy mining anyway, and that's as good as it's going to get.

[07:07:14] So what have we achieved? Nothing, really. All this work, really, we haven't achieved much. Of all those things, I think compact blocks probably achieved the most in reducing latency. But did we advantage the small miner over the big miner or reduce that disadvantage? No, we didn't. And as soon as we start facing the threat, what happens is nobody's big mining illegally. So they all got smaller. They all moved out into the hinterlands, and they're mining their small mines. All of a sudden, latency goes way up, orphan rate goes up.

[07:07:51] And so when people say, oh, orphan rate, latency, it's not a problem anymore. There's no orphans. I'm like, there are orphans. But the reason you're not seeing a lot of orphans is because mining is very centralized. So as soon as it becomes decentralized, you're going to see that it's actually a problem. And that's when it will matter, because that will imply smaller miners operating at a higher cost. As you, I'm not convinced that laundering works, right? Mixers is really sufficient to provide the level of privacy that people need in the threat environment.

[07:08:35] John Carvalho: I've been kind of biding my time to decide what I think is good or bad for privacy, because I've just learned so much over the years. And I just feel like I haven't quite gotten there yet. I have a lot of thoughts about how privacy works that have evolved and a lot of ways to see why certain things don't make sense. But I also have hope. And so I think, okay, maybe eventually if nobody else figures it out, I'll learn enough where I'll figure it out. And that's how I look at it.

[07:09:05] Eric Voskuil: I tend to think that I'm not the smart guy in the room and that other people are going to figure these things out. And I just keep working on what I can do, which is basically just software engineering. I just crank through the engineering.

[07:09:16] John Carvalho: I'm disappointed when I figure something out. I'm like, I figured this out. Why didn't somebody else figure this out?

[07:09:24] Eric Voskuil: When I look at it like a ZK, you know, zero-knowledge proof paper, and I'm like, my head starts spinning. I'm like, I am in the wrong class. I am perfectly happy to let other people, I understand the concept, the print. Well, I'm like, okay, you work on that. Make it small, make it efficient. We'll come back in 10 years to see how it looks. But people are continuing to work on those things. I think zero knowledge, one way or another, gives us the possibility of decoupling inputs and outputs.

[07:09:54] And that goes a long way towards privacy. I mean, there's a certain aspect of privacy where you're transacting with another party, and they know who you are. And there's a potential tainting problem, which is always going to exist, right? But then you've got online interaction, where, you know, maybe you can be as anonymous as you need to be to do the things you need to do.

[07:10:19] John Carvalho: Social graphs, reputation. And these are kind of the opposite of privacy in a lot of ways. And so it's like, how do I figure out? Yeah, how do I figure out how to digitize trust, give people self sovereign identity, but still also help privacy? Like, they're almost working against each other. But somehow they're not quite working against each other. And I'm just, that's why I'm biding my time before taking a position or such.

[07:10:50] How are you doing over there, Vlad?

[07:10:52] Vlad Costea: Oh, we broke Amir's record. It was seven hours, seven minutes. Now we are at seven hours, 11 minutes, 58 seconds.

[07:11:03] Eric Voskuil: But there's two of us, so we only get half credit.

[07:11:08] I'll take half credit,

[07:11:10] John Carvalho: But I'm not going double time.

[07:11:13] Vlad Costea: Basically, Amir cheated a bit because he spent like one hour talking about his favorite mathematicians and dinosaurs and the way that he envisions the future and all of these non technical topics. But this was very consistent. Yeah, that's Amir. But this has been very on topic.

[07:11:38] I'm really proud of it. And we still have Andrea [unclear: Piretta] Or something. I hope I don't mispronounce the last name. Piretta. Yeah. Wanted to know also about social scalability and what you do differently, or what you would like to see differently in Bitcoin, the current state of Bitcoin and critics of Bitcoin.

[07:12:06] John Carvalho: What's social scalability like the user experience?

[07:12:09] Vlad Costea: No, I think it's the concept as defined by Nick Szabo in one of his articles in which he describes social scalability as technology that enables you to interact with strangers that you don't trust and trade with them.

[07:12:30] And Bitcoin is like the ultimate tool of social scalability because you get to trade with strangers around the world and you don't have to know anything except for the fact that you're running the right client and you're verifying that the coins are not fake.

[07:12:47] John Carvalho: I would say on the surface, speaking ignorantly, that does not sound like a sound concept. I would say when in trade and in commerce, part of what you're trying to do is match people. You're trying to say like this person is looking for that. And you're trying to help people, you know, find what they're looking for. And that requires an exchange of information. And so I would argue social scalability requires a certain amount of supporting of a social graph and identity. So anonymity, how do you go from not knowing who anyone is or where anyone is or anything about them to trading with them?

[07:13:25] Eric Voskuil: Yeah, I kind of agree. It's maybe a little different take on it. But there's this tendency among cypherpunkish people to see everybody as a threat and shrink into anonymity as a default mode of operation. What this thing describes is this presumably ideal state of affairs where nobody interacts with anybody else. It's numbers interacting with numbers, pseudonymity or something. We've got this web of trust where we trust pseudonyms, and nobody is actually interacting. And I don't see that as either effective or desirable. I know a lot of people do, but I think it's fucking stupid.

[07:14:21] What I see is individuals working together, generally knowing who we are. I mean, we know each other. We've known each other for years, right? We're working together to achieve some common outcome. And that generally in the anarchist, libertarian, cypherpunkish world means enabling or empowering the individual in the face of the overreach by the state. Why that means we all need to be anonymous to each other? I don't know. To me, when it comes to privacy as an aspect of security, it has to do with being able to operate in a way that you can't be identified by the threat.

[07:15:03] The threat is not every other human being. I mean, every human being is potentially a risk, but it's just not the way the world works. And trying to devise a society, sounds like Nick is advocating for it. To me, it's a non-goal. I don't want to live in a society.

[07:15:20] It's a non-society. It's anti-society. Right.

[07:15:23] It's not even a non-goal. It's a non-thing. Actually, my first reaction to it when you described it was the name was weird. Like, what was it? Social scaling? It's nothing social about it. And it's not really scaling. It's more like effective isolation. We can all be completely isolated from each other, but still be able to trade with each other, which is interesting.

[07:15:50] John Carvalho: Well, to play devil's advocate, I would say maybe what he means is minimizing witnesses, like we talked about earlier. Is there a way that we can, so social scalability of Bitcoin would be getting as many people to use it as possible in a way that they're revealing as little metadata as possible.

[07:16:11] Eric Voskuil: Sure. If metadata gets sucked up by the NSA, then you're on the grid. Minimizing third-party control over two-party voluntary interactions is a laudable goal. Ultimately, my goal is just for people to live freer lives.

[07:16:34] That certainly doesn't mean in isolation or on their machines, their computers. It's just empowering the individual.

[07:16:46] John Carvalho: I think some Bitcoiners took don't trust verify to mean much more than it was meant to mean. And trust is useful. You can't compete without trust. You can't participate in society without trust. You can't scale without trust. There's so many things that you need trust for.

[07:17:05] Eric Voskuil: Low trust societies really suck.

[07:17:09] I mean, there's high trust societies, like you go to Japan. I've been to Japan a lot. There's some things about Japan that are great, high trust society. Some things about it really I don't like and they don't like. But in general, would you prefer to be there or in the DRC? Like a low trust society, I assume. That's one of the places I haven't been. But low trust societies are dangerous and unproductive. And so trust is not an inherent evil. And trust works really well in a free market.

[07:17:50] It's really well, because reputation works. And take a look again, look at Japan, relatively trusting society, and it works. But when you have the state step in and violate that trust, they took all your gold certificates and said, sorry, we're keeping the gold. And that happens on a regular basis. Now you have a different problem. So people talk about getting rugged by banks. Well, banks aren't rugging people. The state is rugging people using the banks. It's this common denominator. Of course, there are scams, and there were banking scams that have happened long ago in history.

[07:18:31] But these are exceptions. The rule is generally that societies operate on trust, like you're saying. Especially, you go back further in time, there weren't mechanisms to provide assurance. I remember writing checks, receiving checks. I remember when writing a check was considered much more acceptable when you're waiting in line to buy something than using a credit card. Credit cards were new enough. They took a long time to process. You had to get out the thing, sit on the desk, do the churn, churn, get the papers.

[07:19:04] John Carvalho: I used to have to do that.

[07:19:06] Eric Voskuil: And they'd have to write out the thing. This was credit cards from the 70s, and I was growing up. And somebody comes along with a check, it's like, they're already done. Let's get done. So if you think about it, both of them were high trust, because the credit card swiping thing, there was no verification.

[07:19:24] John Carvalho: I forgot all about that. You had to take the card and put it in the carbon and slide the thing over. Yeah, but

[07:19:30] Eric Voskuil: What are they doing? It's a dynamically created check. That's what credit cards are. They're dynamically created checks. You get the boom, you write the amount, you get the vendor, you get the card number. Same thing as your account number, and then they send it in. And a Visa company debits your bank account, and they send it to these guys. It's all complicated. But it was much slower. Writing a check was faster. Cash was the ideal. You get in line behind somebody, he starts pulling on his credit card, and you're like, oh, fuck, right?

[07:20:01] He's sitting there for five minutes while they get this done. And now it's the opposite, right? Somebody's paying with cash. They're like, ah, Jesus, just use your Apple Pay or something. But if somebody goes to use Bitcoin, who knows what's going to happen. It's the

[07:20:16] John Carvalho: Same thing, actually. If you go to El Salvador, and you want to pay with Bitcoin, and somebody's behind you in line, well, now the waiter is telling you that the manager has to do it. The manager forgot how to do it.

[07:20:27] Eric Voskuil: Right, right, right. It's just not, yeah. But the point was high trust, right? So any form of payment had some fairly, cash was fairly low trust because counterfeiting was not easy. And then credit cards were pretty high trust, and checks were pretty high. Until you get, again, you get the list of checks behind the guy at the cash register. Don't take checks from this guy. And you still see that once in a while. It's every kind of funny. They've been up there for 20 years. But that's how it worked.

[07:21:03] And yeah, there were problems with that. People maybe didn't see, right? There were problems behind the scenes. And there's money printing and inflation. But it's all tax.

[07:21:14] John Carvalho: There was a department store, and we used to keep a Rolodex. And so people who tried to use fake checks, people who tried to return stolen things, return used things. And we had this Rolodex where anytime anybody was behaving suspiciously, we would look and see if they were in the Rolodex.

[07:21:30] Eric Voskuil: And that's how credit bureaus got started. Big stores started keeping what you're talking about. And then that got to be a pretty big list, right? And they started pooling their lists for common benefit. And that's what gave birth to the credit reporting agencies. That's how it happened. That just makes sense. It's a market solution to a trust problem, right? OK, so these people have caused those problems in the past. So we're not going to extend them credit. If they've got cash, we'll sell to them. That's what credit reporting is all about, not extending credit.

[07:22:01] And why should anybody have to extend credit to anybody else? There's no reason, again. But we've got all these regulations controlling the credit reporting agencies, and regulations controlling credit cards, and all this other bullshit. If you want to buy something, just pay cash. But the idea that we're going to live in a zero-trust society, and that's kind of some ideal, which seems to be some people's mentality, to me is not a goal. It's like they haven't really contemplated what that means. And I think some of it comes from some of the science fiction that's been written about dystopian futures.

[07:22:40] I would say,

[07:22:41] John Carvalho: Even digital only, it's not feasible. In other words, you could say, oh, yeah, yeah, I understand about society, but online. No, even online, you need to use trust. It's everywhere. Right.

[07:22:55] Eric Voskuil: I mean, yeah, if you think about it, the level of trust that people extend to each other on a continual basis is very high. People translate my books, and I said, yo, I'll pay you full royalties for two years. Two years later, I'm like, send them some Bitcoin. They're like, oh, I forgot about that. Like, yeah, but it worked, right? How else would we have done it? I don't know. I'd have a contract, and back to all this shit. It's like, no, we don't need a contract.

[07:23:18] Trust me or you don't, we did it, and it worked.

[07:23:23] John Carvalho: Anything else, Vlad?

[07:23:26] Vlad Costea: Sure. I mean, it would be very useful since one of the sponsors is HODLING.ch and they're specialists in self-custody to hear some of Eric's opinions about Ledger, which were part of the conversation that we were having before we went live. Yeah,

[07:23:43] John Carvalho: So we've been here even longer than the seven hours and such. There was another 30 minutes before that. Yeah,

[07:23:50] Eric Voskuil: Can we get credit for that?

[07:23:54] All right, so I don't know if enough has been disclosed on what actually, there's been quite a bit disclosed right off the bat, which is great on what happened, but part of it is I never kept up with hardware wallets after the first few years. I was working on one initially, so I had quite a bit of knowledge, and I was working on one before Trezor even came out, and then Ledger came out. I've always felt that a security model and the assumptions that Trezor publishes along with the security model, which is essential, right?

[07:24:34] You have to publish your assumptions that you're operating under have been very reasonable. They've always been reasonable. Again, I don't keep up, but that has always been my assessment from early on. I don't really know what's happened in more recent times. But Ledger, the first time I saw them, I think it was a CoinDesk article about a new release. It was the first one, like 2015 maybe.

[07:24:59] Vlad Costea: Was it BTChip or Ledger?

[07:25:03] Eric Voskuil: It was called Ledger. Actually, so today, I went, the thing, all the discussion about this, there's a lot of discussion between me and Eric Larchevêque, I think his name is, who was the CEO of Ledger at the time, maybe still today.

[07:25:24] It all occurred in Disqus forums underneath these articles. It was a series of articles over the years. He at least twice came up on these threads where basically, the article comes out, Ledger, whatever, just released, it does all these great things. I read it. Just based on reading the article, I go, well, that's a security problem. I make a comment and a little Disqus thing at the bottom of the thing. These are all gone now, all these forums just vaporized when Disqus shut down. I was able to recover my login and go in and see my own post today.

[07:25:58] I reposted, if you saw, I tweeted a screenshot of one of those old Disqus posts, which were from one of the later releases. I was quoting from the article, and I just made a comment on that. This is how these threads got started. I reviewed. I didn't look at any of their source code. I didn't go beyond reading an article about them in a CoinDesk or something, and maybe a little bit of reading their documentation.

[07:26:28] I have a history of doing this. I started a software company, a network security company, and one of them, BeyondTrust, is still out there. In the process of running that first company, I inferred major security vulnerabilities in a competitor's product by just reading their press releases. A little bit of their documentation, not even ever running their software. I was able to get one of my employees to verify what I said, and then we wrote up. That resulted in three CERT vulnerabilities being published against them after we had informed them, and they denied all the stuff.

[07:27:08] They had basically copied our software and done it poorly, so we understood it really well. I had some experience with just reading documentation and going, yeah, I think there's a conceptual problem here that's maybe big enough that people tend to overlook it when they're looking at the details. If you know me, I tend to look at the big picture first, and then I look at the details. The first ledger was a USB stick, no screen, nothing, just plug it in. I had some software that went on your PC, and it had a little plastic card, looked like a credit card.

[07:27:42] The card had a number on it. It was numbers and letters. I think it was like four sets of four numbers and letters, and they were all like base 58 pairs. In other words, there might be a B, which got paired with a seven, just pairings of base 58. And so the idea was, and this is... Bear with me, this is relevant to the current issue. This was the case with each of the iterations I saw. The idea was that you plug the USB stick in, and it made it cheaper by not having any kind of UI, no screen on or anything like that, and you put software on the machine.

[07:28:28] Now, the presumption of a hardware wallet and the presumption of this whole credit card thing was that you cannot trust the machine you just plugged it into. The machine is the threat. The hostile software is running on your machine, and you know this for a fact, and that's why you've got this little plastic card. You put the USB stick in, and you tell the software you want to sign this transaction somehow, and the software presents you a prompt for several characters in the address of the payment that it's going to sign.

[07:29:07] It asks you for the corresponding letter on the card. It prompts you with a seven, you give it a B, and it prompts you with four of them. What's 58 divided by four?

[07:29:22] Vlad Costea: You never remember. 14.5.

[07:29:25] Eric Voskuil: Okay, that's good. Remember that number. You do that once, and it's basically you've provided to the threat software, to the machine, the answer to four of the possible 14.5, to one of the possible 14.5 scenarios, or to four of the 58 values. You've given 4/58 of the secret to the machine. Now, keep in mind, the machine doesn't need the whole secret. It only needs to match four. This has to be the right four. So you go to send some money, you say, I'm going to send to this address, the thing pops up a prompt, and you give it the thing that proved you're not malware, you have the card.

[07:30:09] So you prove that you have the card. And so the software then sends those numbers over to the signing device. The signing device correlates those answers to the address of the payment. So if you didn't have the card, and you didn't give the right response, it won't sign. So that's how you work. That was their theory on how you work your way through the malicious software on the machine. So let's assume now your machine's in a botnet, and every single machine in the world has been attacked by this thing, and it knows Ledger.

[07:30:45] So as soon as it sees Ledger software come up, it replaces it with its own version. It does an injection attack or something, and it's presenting you with this prompt, and it just does what you say. The USB stick says, I want to sign this thing. Here, give me these four values. You type in those four values, it goes back to the USB, and it signs it. No harm. You do it again. And maybe every time you do it, it chooses four different values. That would be kind of an ideal case.

[07:31:12] So how many attempts does it take before the malware has your entire card? It takes 14 and a half payments, and it has the entire card. But it doesn't need the entire card. It just needs to get lucky that it just needs to have enough addresses to pay to for itself that it can take those four values and send the payment and the values to the USB stick and have it sign. So after 14 and a half tries, it's pretty much assured that the malware can drain your wallet probably much earlier.

[07:31:49] And you could probably even short circuit that by causing the app to crash and then reprompting you again. For a different set of pairs, right? So so horrendously insecure. And I pointed that out at the end of this article. And eventually it came to be acknowledged. It's kind of understood, but not until a new release was out. And this is what happened with my competitor software situation as well, right? So this is why there's screens on these devices. This doesn't. This model does not work. And so when I saw people talking about, okay, well, the guy with a lot of experience, right, signed a big ass payment using a ledger device, and it's being described as a what kind of payment?

[07:32:38] What kind of signing? Not transparent, but a blind blind, right? Blind signing. That's what this was, right? That's what what I just described to you. If effectively, it's effectively blind signing. Where like the the malware on the machine can sign for itself if it wants to. In other words, the software can present you something and you don't have any you don't go to the screen and check to make sure what's supposed to be happening. You just trust the software on the machine. And they had to do that in the first word of the software.

[07:33:11] So that's why I to my to me in my head, I'm like, okay, that sounds familiar. And anybody that would implement what I just described to you in the first version of their product and defend it as secure, right? Doesn't understand security at all. And that and that's what was always bothered me about ledgers that they would actually. So version two came along. And then version three and and in both of those versions, there were major security lapses. One of them was almost as straightforward as the one I just described to you.

[07:33:41] The other one is a little bit more convoluted, but but not as convoluted as what just happened. Oh, so very feasible. And in one of the scenarios, I said, I said it was me discussion between me and Mr. Larchevêque there. And I was like, look, you're saying that this can happen. But all that has to happen is, you know, a bunch of machines on a botnet are under somebody's control, and they can just start draining everybody's wallet. So I'll give you I'll give you one other example.

[07:34:07] And again, these are these are based on the history of something that sounds similar. It may not. It's probably not the same scenario, but it's a history of very cavalier approach towards security, or at least inexperience, and defending, you know, what I consider indefensible security, and then just waiting till the, you know, saying, Well, the next release is going to solve this and this kept up. So the I think it was the second version got much more advanced, they came out with a secure element, you probably remember this, right, it was a big thing, you got a secure element.

[07:34:39] And then what they were advertising was bank level security, because banks have the chip cards have secure elements in them, they're tamper resistant. Or tamper evident or something, right. So if you so there's a so so these cards, like your your credit card that has a chip in it, it can, you know, it doesn't give up the secret, it's it gets a prompt, and it signs and it provides an answer. And that, you know, it's your, your basic proof of possession of the thing. So what they did was they in this is was in their documentation, they produced four secrets, public private key pair secrets.

[07:35:18] They published the public key public keys of all four in their documentation. So it was very clear that there were four secrets on all. So the batch, the devices were made in four batches. Each batch had a unique and a different secret in it, but only four total secrets. And these the public keys were published in the documentation, just to kind of, I guess, show how it worked. And they were referred to as attestation keys. And then whenever I see attestation, I might, you know, my spidey sense goes, because I don't like with secure computing attestation, I find complete nonsense.

[07:35:54] The idea is, is that I can attest to be something or to have something. So you plug in a hard drive, and it can say, I'm one of these, right, and it couldn't possibly be faked. Well, that's just nonsense. But an attestation key in this case was basically providing the assurance that it was like a legitimate device or something. And that allowed the bootstrapping mechanism to take place between I think I'm like a mobile device and the thing. Anyway, I can't remember all the details. But the whole point of this was everything hinged on the lack of disclosure of these secrets on these devices, obviously.

[07:36:30] Now, when banks make you a credit card that you can use to prove you have it, it's your account, they put a secret on that card, that's your secret. Not everybody's sharing the same secret, right? It's not saying this is a Bank of America card, and that's good enough. No, this is your card, and you can use it, right, to access your account. So that's bank level use of these things. What they did was shared secret, right? Everybody was sharing the same secret. So four secrets, right, but it doesn't matter.

[07:37:00] So what I did is say, well, if I got one of these secrets, like if I was in the chain of custody for the production of these devices, and I somehow got one of these secrets, what could I do? Well, it turns out, if I could just get, you know, at least, I mean, certainly with root level access on their machines, I could drain wallets, I could interject myself into the bootstrapping process between what became their screen, which I think was a mobile device at the time, no screen still, but they were using different ways to try to avoid putting a screen on the device.

[07:37:32] And I could basically, even if they had already bootstrapped it, you could fault the thing, cause them to have to do it again, most people would go, okay, I'll do the thing again. And boom, you own it. You could prove to be the device to the screen, and you could get it to sign whatever you, you could, you know, cause it to sign whatever you wanted. So I went to a hardware hacking course in Portland, and I talked to some guy that took the course, and I talked to some, you know, famous guy that wrote like the Linux hacking book, big thick ass book, and great guy.

[07:38:07] And I asked some people, like, one of these guys had worked at a place in Seattle where I lived at the time that had the ability to shave down a chip and read off data, like actually read using, you know, electron microscope, what on the chip, like, what, what does the memory say? And I said, so is this, is this hard? He says, well, you know, there's a certain failure rate, so you want to have probably more than a couple of them. And he said, but it's definitely possible to shave down the, you know, you just kind of shave them off until you get to the point where you can see that the actual state.

[07:38:39] And he said, I think he said at the time, this was going back like eight, years or nine years, it was, it was like $100,000. It was about what it would cost you to do that. I think it's far cheaper now. But even so, I was like, man, $100,000. I could, I could, I could dig really deep, maybe get some, get some people together and just take one, you know, just get one of these things on, you know, and shave it down and get that secret off it.

[07:39:03] And if I had that secret, all I had to do was put out, you know, kind of take some botnet, and put out some malware on everybody's machines and just drain all their wallets. This, who knows how much money there was on all of them, certainly more than $100,000.

[07:39:16] John Carvalho: You could do it for all of them.

[07:39:19] Eric Voskuil: Well, I can do one quarter of them for that, for that one. I said for $400,000, you could do it for all of them. For $400,000 I could drain every Ledger wallet back then. Right? That was the upshot of it. That was an interesting conversation. There was another one that came out. I forget the details of the other one. After the third one of these discussions, I just stopped. I was like, I'm not working in this anymore. I don't really care. But I was never surprised every time I saw something. One of the aspects of the third one was that it was multisig. Basically, the recommended approach was to bring all the signatures together on a single machine, which defeats the purpose of multisig.

[07:40:10] I pointed that out. Again, with malware on that machine, that was the signing. The platform, which again was untrusted, then you're effectively doing single signature in a compromised platform.

[07:40:25] John Carvalho: Did you ever look at the Bitkey device from Block?

[07:40:30] Vlad Costea: Oh, from Jack Dorsey?

[07:40:32] John Carvalho: Yeah. It's a screenless hardware wallet. It might be your new pet thing too. Dismantle. Yeah. I don't remember the security model. It's a bit different because it is multisig across multiple devices, but it is not having a screen.

[07:40:58] Eric Voskuil: Right. I remember getting into, because I had done all that work on a hardware wallet that had a lot of features like BTLE and QR code scanning and all the bells and whistles. I looked at all this stuff and I'm like, you're talking about blue. Blue is handshaking to establish trust. I'm like, that's not a great idea.

[07:41:25] I don't know. I suspect that it doesn't sound like the operator really, he might not have been cautious enough, but I think there was an assumption of the level of the type of security that was being provided and probably wasn't. It sounds like it was a laptop, desktop, whatever application on a machine where the machine itself had been compromised, which is the standard scenario. You should always assume the machine's compromised. Right. And you plug in the USB thing, which I guess now has a screen, and the app pops up and you verify you're looking at the right transaction.

[07:42:06] There was a question about how do I know what the transaction is supposed to look like? It's too complicated. It's Ethereum contract, blah, blah, blah. But to me, I was like, that's not the interesting question. Let's assume this guy knows what it's supposed to look like. But we know that the machine was compromised. That's what's been reported, right? North Koreans compromised the guy's machine. So presenting him something to sign, which he thinks is his transaction, but it's actually draining his wallet and sending it to North Korea.

[07:42:30] Vlad Costea: Right. So for context, we're talking about the Bybit exchange hack, right?

[07:42:35] Eric Voskuil: Right, right, right, right. So yeah, it's probably good for somebody who watches it.

[07:42:41] Vlad Costea: Was it clarified or confirmed? Late context. What's that?

[07:42:48] John Carvalho: Was it confirmed they use Ledger?

[07:42:50] Eric Voskuil: It's been reported a number of times, so I think it's the case. I'm only seeing what's coming up on Twitter. But I think it was the guy that did it. He was very open about what happened. He said he did this thing. Just the term blind signing, right? That's what got me. It's like, we know from what's been reported, at least we believe from what's been reported, that the machine was compromised by malware, which is not that hard to do. You assume that's the case. That's why you're using the stuff in the first place.

[07:43:24] And we assume, I assume, that the device was not compromised. Plug in the device. Machines compromised, has a single fairly straightforward transaction, Ethereum contracting, but still, he's going to authorize this transaction in this kind of cold wallet signing process and authorizes the signature. Basically, what that means is gave whatever the USB stick needs from him, the secret handshake, to tell it to do the signing with the keys that it has on board. So maybe that was a push of a button on the stick or something, right?

[07:44:06] But how does he know what he's signing? Well, either that's on the screen of the device or it's on the screen of the machine. But if it's not on the screen of the machine, why the hell is the device even plugged into the machine?

[07:44:18] John Carvalho: And why are they doing all of this on a hot machine? Well, I don't know. One point four billion dollars of money. Like, why? Why is it touching a machine?

[07:44:33] Eric Voskuil: I mean, it was me. I think I would.

[07:44:35] John Carvalho: I mean, all right. So actually, maybe this is a good question. Should we believe this guy? Well, you know,

[07:44:42] Eric Voskuil: It happens. So I think, you know, I mean, so so the money disappeared somehow.

[07:44:46] John Carvalho: So what if North Korea paid him five hundred million dollars to do this?

[07:44:50] Eric Voskuil: Right. So maybe maybe it's maybe it's an inside job. That's the only other explanation. Right. Either it's it's it's some kind of hot machine or it's an inside job. I don't know how else you would if you would describe it. I just

[07:45:02] John Carvalho: I would like be so scared if I had one point five billions of dollars that I could lose. I would never touch a machine. I'd be like taking the address, putting on a USB stick, taking the USB stick to a cold machine, copying the address. You know, I would not. It would be all offline.

[07:45:20] Eric Voskuil: You'd be typing the whole transcript in JSON, right? One character at a time. I've done it. Yeah, I know. You know, you have like a like a BBB inside of a, you know, what do you call it? Faraday cage. Faraday. Faraday. I see me with names again. Be inside a Faraday cage with the whole thing. So I don't know. But I think, you know, I tend to I tend to kind of lean towards the you know, it's much more likely that things are just just stupidity tends to win out over malice most of the time.

[07:45:59] But but I think

[07:46:01] John Carvalho: I can point out that like Tether moves billions of dollars regularly and they somehow have never done this. Yeah.

[07:46:06] Eric Voskuil: OK. But let's look maybe like look at the human factors here, right? Like if if for some reason people believe what they're messaged about things like Ledger, right? They might get complacent and they might put it in there and get I got a hardware wallet. It's keeping me safe and I can just come in here and do this thing and it's going to be OK.

[07:46:32] And, you know, it doesn't happen very often, but that's what people believe that's going to happen once in a while. They're going to. And this was my beef with it all along. It's like, yeah, this can work sometimes. A lot of times, you know, but if you're assuming that the machine is you know, you can do this on a hot machine and that machine has not been compromised, then why do you have the device at all? Right. They just use the machine. The machine has to be secure to just use the machine, use Electrum and use the machine.

[07:47:02] So that is that is a perfectly viable approach to have your your your never touches any kind of network, you know, operates inside of a Faraday cage, individual device that has your wallet on it. Right. That doesn't have you know, doesn't have a hardware wallet. And you just do that and then you just kind of, you know, retype the transaction onto you. You know, once it's signed and you verify it every single bit in the in the JSON or whatever it is. Right. And then you copy it over to a hot machine somehow.

[07:47:28] Take a take a picture of it or something. So you can

[07:47:33] John Carvalho: Hope it has a QR code. You could put it on a USB.

[07:47:36] Eric Voskuil: You got to put it on a USB. You're transferring the USB from device to device. Then you got.

[07:47:40] John Carvalho: Well, it's already signed. Right. So nothing else bad is going to happen. Yeah. Just trying to figure out how to get it online.

[07:47:45] Eric Voskuil: Now that USB is being as long as it's a brand new USB and you plug it into one machine and then the other in the right direction, you're probably OK. But, you know, going back and forth between your USB could be transferring malware. So now you got a potential problem the next time. So, you know, I mean, it's it's it's a lower probability, but malware can be transferred by USB. So, again, another one of these things.

[07:48:08] John Carvalho: You could output it as a QR, though. You could output it as a QR and scan it.

[07:48:11] Eric Voskuil: Right. There's there's that there's a there's a there's there's options. But, you know, I don't know if you've seen these like these things that like parabolic dish that can they can like look across the entire room. And like this was a decade ago. Can can can based on the power fluctuations. Oh, yeah.

[07:48:33] John Carvalho: I've seen they did analysis of how the sounds of your keyboard vibrated a bag of chips and they were able to discern the distance of the keys from the chips. The crazy, crazy things. Yeah.

[07:48:49] Eric Voskuil: Like, well, this is I was I was the computer security officer in my flight squad when I was in the Navy going back. That started like 30 years ago, 95 ish, 94.

[07:49:05] So, you know, you've probably heard about, you know, these things are more common. We heard about now, like, what's a SCIF? The Congress, people have to go into the SCIF to talk about secrets and stuff like that was the reason for those things. And these are not really you know, the things we're talking about are not really new. This is stuff that's been around a long time. And, you know, the military level has reasons for taking these kind of precautions. You know, the state of the art tends to be way beyond what people think it is.

[07:49:37] And the question is just how motivated is your attacker? And, you know, how well resourced are they? And, you know, that comes back to what's the motivation. When I was building my hardware wallet, I spent a lot of time trying to understand what, so I did the entire engineering design, and I priced it, and then I decided I wasn't going to make it. So it's sitting on a shelf, physically, I have a physical prototype sits on the shelf. I was lucky enough to have a fraternity brother from college, and I went to Rensselaer, and he was a EE, and he had created, coincidentally in Seattle, a very successful engineering design firm, and they made high end consumer electronics, all kinds of stuff.

[07:50:15] And so I worked with his company for like a year to do the design. And while I was doing that, I also worked with another guy who had, it was another fraternity brother of mine. This guy was computer science. And he had sold the company, you know, basically to the government, to SAIC, that was doing, you know, kind of, he did NSA kind of stuff, right? So the shit that made him a little bit, a lot, actually paranoid. And, you know, we speak in generalities, but I was able to kind of learn from him what I can expect in a threat scenario, like what's the state of the art, like the shaving down the chip thing.

[07:51:00] I don't know if maybe that started just talking with them, and then me going down to the hardware hacking course and trying to find somebody who would be able to do it. But, you know, people just don't really, I don't know, they just don't, don't really take, don't look realistically at threat scenarios. And security is really hard. And a lot of this stuff in the Bitcoin world is just really cavalier. And it's not just like, we're not just talking about these hardware wallets, you go back to, once again, things like Dandelion, or even Mixers, or confidential transactions, at least like, like, every time I look at some of these things, I just wonder, like, who, you know, how does this, how do we get this level of confidence in this solution that we have?

[07:51:44] Because to me, I don't, I don't see it. And so I think that's kind of generally a problem is people think there's some kind of magic, you know, that, or they think the threat's lazy.

[07:51:56] John Carvalho: They put their biases over some sort of, you know, you need to discover the truth entirely. They just say, well, the bias has been satisfied, so I compromise. Good enough security.

[07:52:08] Eric Voskuil: I, my, my feeling is strongly that if somebody says it's good enough, it's not good enough. Yeah, it's, it, you state your assumptions, you know, and if it's secure under those assumptions, you know, and you can, you can demonstrate and prove that and great. Like Trezor started off with a screen. Why? Because they understood this problem. They also understood that if you physically obtain the device, the device was compromised. The threat gets the device, it's compromised. So tell people that, right? Don't assume that people, you know, I lost my device and somehow my wallet got drained.

[07:52:44] How did anybody get in? It's got a pin, right? That's not how it works. It's just not how it works. But you go to ledger guys and then it stops on a tamper proof chip with, you know, bank level security and nobody could possibly get in there. And during that thing, well, it doesn't really work that way. You know, tamper resistant, tamper proof. I always took that with a big grain of salt, right? Like, so it turns out years ago, some guy got it, got a Trezor, plugged it in and he was, he did power faulting on it.

[07:53:13] And there's a nice little video he makes. He shows the whole thing. He's basically able to read the key off the device by power. I think it's power faulting the device. In other words, you're sending signals in that don't conform to the spec for USB, but you're causing the device to do things. And, or there was some, maybe, I don't know if it was signing. He didn't, you know, obviously he was able to extract the secret without the pin or anything else. And this led to Trezor people and maybe core also like working towards constant power algorithms, right?

[07:53:54] So if you have an algorithm like a loop that's running in it, and if there's a branch in the code and the branch goes one direction versus another direction based on logic, and those directions differ in power consumption, you can tell where the code is executing. And you know if that's an A or a B, right? Now, what letter is that? And that's exactly what he did. So it's a great little video. He actually shows, you know, how he derives the entire, he takes the algorithm, I think, which was public.

[07:54:21] And he just uses that to listen to, you know, to the amount of power being consumed and derives the key off the device. Well, people, you know, looked at that and said, oh, Trezor is not secure. And I'm like, oh, bullshit. They said, you know, they said it's not a physically secure device. They were honest with you. They told you how it works. That's the limitation. And I'm much, much better with that than somebody saying, you know, we've got a bank level security. Nobody could possibly get your keys, even though they've got your device.

[07:54:47] Vlad Costea: That's not true.

[07:54:49] Yeah, but you have to understand that Ledger is possibly the company that messed up the most times, but never got punished by the market. Exactly. These guys are market leaders. They have the guy who designed the iPod, I think, not the iPad, the iPod, to do their e-ink devices that they're releasing nowadays. Yeah. So they are working with fashion brands. They actually got someone who did marketing for some. Yeah, they even made some sort of stupid hat.

[07:55:24] John Carvalho: Ledger necklace. They actually did do it, yeah.

[07:55:26] Vlad Costea: They made some stupid hat and you're supposed to fold the Ledger somehow to be part of the design or whatever. And they were wearing it around their necks and whatever.

[07:55:37] Eric Voskuil: Yeah, $1.3 billion later.

[07:55:42] Again, I want to be clear. I have no idea what they've done since the first three versions, but my impression of what they were doing then was not good. And this sounds like it might fall into that category. And my impression of Trezor every time I've looked at it is they make reasonable. So what I'm trying to point out is that these are not necessary issues, right? These are issues of design and competence and honesty and engineering and the approach of keeping it really simple. And there's a lot of value in that.

[07:56:26] I don't use these devices. I don't have any Bitcoin.

[07:56:30] Vlad Costea: That's what I was going to ask you if you actually use hardware wallets because you are working towards designing one.

[07:56:36] Eric Voskuil: No, no, I just use a hot wallet on my mobile phone. That's pretty much all I got.

[07:56:43] I don't even have a screen lock on the thing. I just always unlock. But then, you know, I don't know. Which wallet

[07:56:50] Vlad Costea: Is it? Mycelium? Electrum? Edge. Edge?

[07:56:54] Yeah. Even better. I know Paul.

[07:56:58] Eric Voskuil: So, yeah, and they used to use libbitcoin before they went to be, you know, supporting all these shitcoins. So I, you know, I still like him. He's good. And they were several, there were two contributors to libbitcoin from Edge.

[07:57:16] All right. So yeah, Mycelium might get good too.

[07:57:20] John Carvalho: It's been amazing. I had no idea that we would last this long. Eric, I really appreciate all of your detail and thorough explaining and patience. You too, Vlad. You had to listen to us for a long time.

[07:57:37] Vlad Costea: We're like 10 minutes away from breaking the absolute record, which was set like a week ago. Oh, the absolute record? Yeah. He heard about the fact that you're trying to break the record and he came to the show and he kept talking. They didn't have anything meaningful to say. Oh, yeah, this was a lot more meaningful. That was basically a DDoS.

[07:58:04] John Carvalho: Was there another question somebody had?

[07:58:08] Vlad Costea: Well, I can ask you about some advice on self-custody. Like, if someone's listening up to this point, which is crazy, by the way, you guys are crazy. Not going to happen. Type something in the comments like, no one's listening or something. Type no one's listening. Seriously, write that. If you're listening up to this point, we've had like 2,500 listeners live, which once again is pretty insane when you think about it. I'm trying to imagine just a crowd of 2,500 people standing outside. How many people

[07:58:51] Eric Voskuil: Are listening?

[07:58:54] Vlad Costea: In total, it was about 2,500, but I'm not sure how many of them were constant because some of them dropped in and out. Twitter kicked us out because it seems like it was too long for that platform. We're still live on YouTube.

[07:59:14] Eric Voskuil: Otherwise, I would have taken this a little bit more seriously.

[07:59:19] John Carvalho: You weren't taking it seriously? No,

[07:59:22] Eric Voskuil: No, no. It's just all bullshit. I'm just glad. This is like the fourth one we've done, right? It'll start to sound the same after a while.

[07:59:30] Vlad Costea: I remember the first one that we did, and you spoke for like two hours or three hours, and I was thinking, you know, this is getting pretty long. But I didn't have the stamina at the time. Right now, no problem.

[07:59:44] Eric Voskuil: Yeah, yeah. I mean, I would just talk, you know, like, I remember I did a lot of long ones, because I didn't really, I would just go until they wanted to shut it off. I did one with John Vallis way back, like, I don't know, six years, seven, eight years ago. And it was like, I don't know, it was like seven hours. It was totally unplanned. It was just gonna be like a 30-minute, one-hour standard. I was all dehydrated. I never did one this long.

[08:00:10] John Carvalho: This is new for me. I've done three or four hours, I think, but nothing like this.

[08:00:15] Vlad Costea: It's been really fun to watch how Eric came when the light outside was super bright. And it became darker and darker. And right now you turned on the lights, and it's very dark outside.

[08:00:30] Eric Voskuil: Now you can all see my screen back there.

[08:00:33] Oh, yeah.

[08:00:33] You see my private keys on there? Good.

[08:00:38] John Carvalho: I'll say, as far as you asked for self-custody advice, I'll say, don't tell people how you self-custody. This is a pretty good rule.

[08:00:48] Eric Voskuil: Don't take what I said too seriously.

[08:00:53] John Carvalho: And so that makes it a little bit difficult to give advice as well. But yeah, I used a hardware wallet once. And just instinctively, the next day, I was like, I got to get that Bitcoin off that wallet. Just by nature, I was like, this is not where my Bitcoin belongs. This was a long time ago, and it was a Trezor. And I kept that same device, and about five or six years later, it wouldn't boot. Now that doesn't mean that the Bitcoin would have been totally irretrievable or whatever, so much as I would have been really scared and having a headache and trying to figure out what to do.

[08:01:33] And because I didn't put the Bitcoin there, I didn't have to worry about that. And so that doesn't mean you don't have to worry about wherever else you put your Bitcoin. Of course you do. But you want the way you store your Bitcoin to be compatible with your own capabilities and your own comfort. And if it doesn't feel right, it probably isn't right.

[08:01:55] Vlad Costea: I remember when I tried the Coldcard, and that felt like I'm some sort of masochist. Because it's really counterintuitive. You have to learn how the menu works and the interface, and then you try to use it a month later and you realize you forgot how to use it. So you have to look at some YouTube video and you're like, is this really the way you want to store? As in, it's so complicated, you forget how it's done. Yeah.

[08:02:24] John Carvalho: And they also make Opendimes, which is another not very safe way to store your Bitcoin.

[08:02:30] Eric Voskuil: I also tend to think that there are certain things that make an ideal attack surface in a hardware wallet. If you want to drain some Bitcoin, that's where you attack. So general purpose, off-the-shelf computer, that's your low-threat device for securing Bitcoin. And your dedicated for Bitcoin device is your high-threat device. I think Peter Todd makes this point as well. It's like, if I was state-level actor who wanted to subvert this and have that level of control, why wouldn't I just subvert these devices?

[08:03:17] And it can go beyond that. This actually brings up a point. We probably discussed this one or two shows back, Vlad, but the security issue that I had to deal with in the BX project, where these guys had used a command that we had for generating a seed so that we could execute the commands in demonstration.

[08:03:45] John Carvalho: The core went after you, too.

[08:03:48] Eric Voskuil: There were a couple of guys. There was one, Antoine, I think it was Antoine [unclear: Poinsot], he was pretty good. There was some others.

[08:03:57] But the guys that had an axe to grind, of course, they came out right away, including Maxwell. I was a little bit surprised about Tadge because we didn't have any. We had been on a panel, I think, a couple years earlier together. It was fine.

[08:04:16] But this is the same philosophy. This is what I'm getting at. I personally don't really like, despite having gone through the process of starting to make a hardware wallet, this is like 2013, I've never really been comfortable with it. I totally understand what you're saying, that it's uncomfortable. And so part of it is, even if you trust the people who made the thing, but how do you do that? And that's the primary threat factor. It's like a honeypot for attack. And so I was always the same way with the computer and the RNG, random number generator.

[08:05:04] I'm like, I might trust in this. That piece of hardware that generates whatever on my device, a random number, is the place where it will be compromised. If somebody wants to inject into every piece of hardware that ships a weakness that they can exploit to drain every single wallet in the world, that's what they're going to do. They're going to go to standard, off-the-shelf PCs, and they're going to inject that random number generator with something you can't see, you can't verify. How do you know?

[08:05:38] So I have never, ever trusted that. And that's why one of the first things that we did, I did, we took this tool that Amir had written called SX, which was really for internal use only. We documented it, but it really, it was kind of a hodgepodge of like several different languages, different add-ons, dependencies. It wasn't really, you know, it wasn't a product. And really, it actually didn't have any documentation, but there was like a website link for it or something. And I ended up making it into like a, you know, we renamed it to BX from SX.

[08:06:18] I made a tool out of it. And this is one of the things I did. So there were uses, there were embedded random number generator invocations in several places in the code. So you kind of, you'd be doing, you might not even know, like, by the way, when you do this, there's a random number being generated in the background on your behalf, and it's being, you know, incorporated into the signature or something like that. And so I took all of those out and moved them to one place.

[08:06:48] And I said, and all, as a result, all of those commands, there's almost 100 commands in BX. All the commands that required a seed value had to obtain that seed value on the command line and no longer was embedded. And so I preserved one command that did what he used to do before, which was to generate using the machine so that we didn't, because it not only didn't have to be generated, but it had to be hexadecimal in the right length, et cetera. And so it had some parameters to say, you know, how long do you want it to be?

[08:07:15] And it would generate it in the right size. And so you could feed it into the other command. So it preserved the same capability, but it did it as a separate command. But then I, it was later that, so we documented the fact that this was not, you shouldn't trust this. There were, you know, you should generate your own value and put it on the command line when you're doing these things. We did that by saying, this is a, this is a pseudo random number generator and it's, you know, it should not be, you should not trust pseudo random numbers.

[08:07:45] And there was a case where, so Bitcoin Core uses, what's it called, for Windows builds.

[08:08:01] So there's, there's a kind of an environment where you can, you know, you can do like a GCC, Clang compile for Windows instead of using Visual C++ for Windows. And in this environment, it basically is providing abstractions of, or general, sorry, implementations of Linux APIs that don't exist on Windows using underlying Windows APIs. And in this one case, the random number generator, they just generated the same number every time. It's like they just gave you a constant. And, and so this, this was out there for years, and it was actually, there was vulnerabilities in certain Bitcoin applications because of it.

[08:08:41] A similar one happened on Android. There was, there was, I think MinGW was the technology I started. So, so, so it, it, it, it, it validated, you know, my concern that you really can't, you can't even remotely trust this thing. And so we moved it out. And that's, so that's just, all I'm doing is making a, you know, a comparison between that and the use of hardware wallets. If, if the device is kind of dedicated to this purpose, it becomes the threat vector. If the device is, you know, a general purpose device, like a computer, I mean, you know, you could attack, you could, you could inject all computers with malware that attack your, your wallets.

[08:09:24] But that's a much bigger task, and that's harder to conceal.

[08:09:31] You know, if you want my advice, you know, use it, use the oldest laptop that will run your wallet software, and don't connect it, don't ever connect it to a network, you know, operate it in a Faraday cage and, and then find some way to transfer your signed transaction to, you know, to the network without compromising your machine. That's, you know, that's a little more technical. I think

[08:09:57] John Carvalho: There's something to be said for using older or more obscure chips for your generation if you're going to use a chip at all, because probably most majorly manufactured chips do have backdoors by governments or more and more governments. But certainly don't use,

[08:10:14] Eric Voskuil: Don't use a chip to generate your random, randomness.

[08:10:17] John Carvalho: Well, I wanted to show you, have you seen these before? Yeah, yeah, yeah,

[08:10:21] Eric Voskuil: Yeah, there's, there's, there's all kinds of dice and those things and whatever. But, you know, even just a set of dice, but you know, you have to, you have to kind of even rolling dice. Maybe that's why those are better, right? Because, because there's human, there's human bias, even in things like dice rolling, which ones you, you know, you selected. But, you know, I find it kind of surprising that there are major wallets that still rely on the hardware random number generator. And I think Bitcoin Core does.

[08:10:52] And it, it had, like when I did the research on this because of the issue, and I document all this, if you read the, if you read the response I wrote to the CVE, you'll see it all in there. But they literally say, this is the comments in the code. They do, they generate this random number from the hardware, which has to pass through C language to the, to the, to the application layer, etc. And if the trust each of these layers, and because once you get it to the, to the actual keys, right, there's no way to verify it.

[08:11:25] There's no way to verify a bias. Not in any reasonable way, anyway. So, they actually said, so they put some obscurity layer over it. And they actually commented that this should, this should help delay an attack. In other words, if your, if your random number generator was exploited, this will make it harder for people to actually carry out the exploit. So, acknowledging that, that the random number generator was a problem, but saying, ah, it's good enough, we'll put some obscurity over it. And so, I think that, that to me, that was pretty damning.

[08:12:03] You know, my, my recommendation for generating seeds is, you know, you know, your, your bucket of bolts or, or, or some dice or something. But also, you know, there are, there is documentation about how to do that properly to avoid biases, especially with just basic dice. And I, and I strongly recommend that. So, you know, specialized hardware. I mean, I'm not knocking all hardware wallets. But I, but I do think that specialized hardware presents a specialized risk. I

[08:12:36] John Carvalho: Think one interesting detail you left out of your story was that part of the reason why it was discovered was because they had put your example random number generation function into Mastering Bitcoin, right? So there were people that were using it as an example, and they were generating wallets out of using Mastering Bitcoin, I believe. Right,

[08:13:00] Eric Voskuil: Right. So it was, it was, you know, it was documented as, you know, examples of using BX. And there was a, there was a theory that I personally had, had like backdoored Mastering Bitcoin in order to achieve this outcome. And the theory was based on the fact that, so we made it, we made a change to the implementation. And in this, again, in the CVE write-up, I wrote the entire history of all those emails in there. There's the, there's the, there's a repo stuff. There was a lot of assumptions made about what happened, which wasn't the case at all.

[08:13:37] We had a, Amir was working on Dark Wallet, I think. And he was, he was, he had written some script to iterate over key generation just to, just to do some experimentation or something. And it was really slow. And it turned out that the reason it was slow was because we were, this code that was using the hardware random number generator was re-invoking the generation each time. Like there's a way you can kind of cache a seed and it kind of keeps feeding off the seed, which is much faster.

[08:14:16] Anyway, so I looked at it and I said, well, yeah, this is, this is not really doing it the way it should do it. It was doing it the way I think Amir originally coded it. But if you really wanted to do like a high volume of these things, it wasn't great. And so I looked at it and said, we really, really shouldn't be using this at all anyway, because it's documented as insecure. And so I, I made it explicitly insecure. I said, you know, put a, put a clock seed in a Mersenne twister.

[08:14:43] And by the way, you know, the Mersenne twister is not a, it's not a cryptographically secure pseudo random number generator. But it just happens to be the one that I think MinGW used underneath, you know, the operating system implementation. So again, it's just, you know, these things are, they were not intended to be secure random number generators. For that, you need a true source of randomness. And there is no true source of randomness on your generic PC. And there's no way to know whether that's a true hardware number generator under your PC.

[08:15:15] So they're inherently not secure. So anyway, I changed that implementation and it probably coincided with the release of a major, we went from like a version two to a version three, a major version change. And Andreas had written, without contacting us, he had, he might, he had some interaction with Amir, but he just said, hey, I'm going to put this stuff in the book. And Amir contacted me. I published some of these emails. He contacted us and he said, like, Andreas is going to put BX in the book.

[08:15:47] This is, I think the first release of the book. And I said, oh, that's cool, but not BX, it was SX, right? And he said, if you can get it cleaned up, we may be able to get like, you know, a good release into the book. So I spent some time, you know, cleaning it up, but he shipped with version two, I think. I think I had this right. He shipped with a version prior to that in the book. And so when we released our release version of BX, the book was wrong.

[08:16:13] There was a whole bunch of differences in the book. And so I took it upon myself to do a pull request into his book to rename commands to all the RNG commands had to be passed through the command line. There was a number of other things, but basically, and the command. So he had named the chap, the pages on the book after the command. So the command changed from something to something else. Right. So what that meant was there was a rename of a page. So when these people wrote up this vulnerability, it looked like I had created the page from scratch using the same version of BX that they used or the latest version.

[08:16:54] Whereas really what had happened is Andreas had checked in all the code originally, and I think I had nothing to do with it, no input whatsoever. And then I found out that he had shipped this thing and I asked him if he wanted me to issue the changes for the new release. So the book would be current. He said, yeah. So I strictly only implemented the changes. It's like I don't change any of his terminology or anything. But what that meant was that one of the page names changed and it looked like it was a new page that I just introduced.

[08:17:24] So these guys shit all over me for injecting this thing in, saying, hey, do this. Where Andreas had written the whole thing. And I even added this is like probably the only text I added that he didn't have. I said, you know, this something about the random number generator command being pseudo random or not being.

[08:17:49] There was some there was some disclaimer there like that this is oh, there was a there was a claim, the statement that the random number generator was based on that trusted the hardware, something like that. Right. Because I didn't like that this was being used. And there was like nobody was being told where the randomness was coming from. So I told him it was using the hardware, which in our history had you know, was you know, there was a clear indication that that meant it wasn't to be trusted.

[08:18:15] Maybe could have been more explicit, like don't trust this value. It's using the hardware. But again, I wasn't rewriting his book. I just took what he said and continued it. So if we had done nothing except just let him take SX and use what Amir had there originally, it would have used the hardware random number generator, which is insecure. And on something like MinGW, it used the Mersenne twister and use the constant value. So, you know, we ended up just removing the command altogether because you could never you know, it was just too much conflict.

[08:18:47] And I didn't want to give people the impression that we're trying to keep people misusing it. People misused it. So we took it out. But it's much more tedious now to like use a command line to like generate some random keys and show people how addresses work and do what's just primarily what it's used for. It's used for demonstrating the behavior of Bitcoin. It's called an explorer.

[08:19:11] So, yeah, that was that. But, you know, we and we we have the internal communications about why we were doing these things as well. I think on Slack, which might go way back, it's like we don't trust this hardware. We're not we're not going to ship embedded random number generators.

[08:19:32] So my my opinion is don't, you know, don't trust the hardware if you're serious about it.

[08:19:43] So the hardware that's dedicated to things like Bitcoin.

[08:19:48] Vlad Costea: I'm going to have so much fun timestamping this eight hours, 20 minutes.

[08:19:54] John Carvalho: Surely there's A.I. That can do that for you.

[08:19:57] Vlad Costea: Yeah, but even for that, I have to cut it because on YouTube I have a character limit of 5000 or something. So I need to select what is really important.

[08:20:07] Eric Voskuil: For all we know, Vlad is an A.I. We've just been, you know,

[08:20:10] Vlad Costea: Talking to this bot the whole time.

[08:20:12] Oh, haven't you met me in person?

[08:20:15] Eric Voskuil: Yeah, but I don't know. We've met a couple of times.

[08:20:21] Vlad Costea: I remember seeing you in Riga. Yeah,

[08:20:23] Eric Voskuil: We met at the last Honeybadger I went to. Yeah, I didn't go last couple of times.

[08:20:29] Vlad Costea: You had a very cool pair of Vans and I became jealous. So I bought one for myself.

[08:20:34] A pair of what?

[08:20:34] A pair of Vans.

[08:20:36] Eric Voskuil: Oh, my Vans. You like the Vans? Yeah. I still have lots of Vans. That's good to hear.

[08:20:43] John Carvalho: All right, guys, I'm getting a headache. I need to go.

[08:20:46] Eric Voskuil: Me too.

[08:20:47] Vlad Costea: OK. Thank you very much for being here.

[08:20:50] We broke the record? Yes, we did by 10 minutes. All right. That's good enough.

[08:20:55] John Carvalho: It was great hanging out with you guys. Thank you, Vlad.

[08:20:58] Vlad Costea: See you around. Thank you, John. Thank you, Eric. And also thanks to the sponsors, SideShift, Citrea, LayerTwo Labs, Bitcoin.com News, NoOnes and HODLING.ch. Bye.