What I Learned Presenting "Blockchain for Beginners"

I just gave the talk Blockchain for Beginners, a beginner-friendly walkthrough of how blockchain actually works, aimed at people with zero background. This is my first time giving technical talks, and it revealed something interesting: the questions you get afterward are often more revealing than the talk itself.
I wanted to write this up while it's still fresh, partly to say thank you to everyone who asked something, and partly because a few of the questions pushed me to think harder than I did while preparing the slides. Here are the four that stuck with me most.

"Where did blockchain actually come from?"

I hadn't planned much history into the talk, so I gave the short version: Bitcoin was created by a pseudonymous person (or group) using the name Satoshi Nakamoto. One of the core motivations was frustration with how traditional currency works: Governments and central banks can print more money whenever they choose, which gradually erodes the value of the money everyone already holds. Bitcoin was designed as a direct counter to that: a currency with a fixed, hardcoded supply cap of 21 million coins, ever. No central authority can decide to print more.
To this day, nobody knows who Satoshi Nakamoto actually is. They authored the original Bitcoin whitepaper, mined the first coins, corresponded with early developers for about two years, and then simply disappeared from the public. It's one of the more genuinely mysterious footnotes in modern tech history. "So he just created bitcoin and left, saying bye bye." Hearing this, I could tell the audience found it as fascinating as I do.

"If Bitcoin has a fixed supply, what happens when it runs out — how will people pay for smart contracts?"

This was the question that sent me down a rabbit hole afterward, because my answer during the talk wasn't quite complete, and I want to correct that here.

A couple of things worth untangling:
First, Bitcoin and smart contracts are mostly separate worlds. Bitcoin's scripting language is intentionally limited; it wasn't designed for the kind of general-purpose smart contracts people usually mean (self-executing agreements, DeFi apps, NFTs, and so on). That world mostly runs on Ethereum and similar platforms, which have their own currencies (Ether, or ETH) used to pay for computation, which is called "gas." So strictly speaking, "running out of Bitcoin" wouldn't directly stop smart contracts from working, since they're not paid for in Bitcoin in the first place.

Second, Even Bitcoin itself doesn't really "run out" in a way that breaks the system. Two things soften this:

• Every bitcoin is divisible down to 100 million units called satoshis, so scarcity doesn't mean unusable, just smaller and smaller fractional amounts changing hands.
• Miners aren't paid only by new coins. They also collect transaction fees from whoever's sending money. As the mining reward shrinks over time (it halves roughly every four years), fees are expected to gradually become the main incentive keeping miners securing the network, well before the last bitcoin is mined around the year 2140.

I appreciated this question because it forced me to be precise about something I'd been a little loose on in the talk itself, the difference between "Bitcoin running low" and "the whole system grinding to a halt." They're not the same thing.

"Couldn't someone short Bitcoin, attack the network to crash the price, and profit from the short?"

This was, genuinely, the sharpest question I got all day， and I want to give it real credit rather than downplay it.
During the talk, I'd argued that large stakeholders in Proof of Stake systems have little incentive to attack the network, since doing so would crash the value of their own holdings. This question exposed the hole in that argument immediately: if you hedge with a short position first, you can profit from the very crash your attack causes, even if your staked coins get destroyed in the process. This is a real, documented critique of Proof of Stake security, sometimes called a "short and attack."

What actually limits it in practice, as best I understand it:

• Slashing still happens regardless of price - The attacker's staked collateral is destroyed by the protocol itself, independent of whatever they make on the short.
• Acquiring enough stake to pull off the attack is itself extremely expensive - Tends to push the price up while accumulating, which working against a short position, not for it.
• A short position large enough to make the attack worthwhile is hard to hide. Unusual borrowing activity or open interest spikes tend to draw attention before an attack executes.
• Communities can fight back after the fact. If an attack is detected, the network can coordinate a fix. This is essentially what happened after Ethereum's DAO hack in 2016, where the community executed a hard fork to reverse the malicious transactions.

So it's not a fully solved problem. It's a genuine, ongoing tension in how these systems are secured, and I'd rather say that honestly than pretend Proof of Stake has no edge cases.

"What does a blockchain developer actually do, day to day?"

I got this one near the end, and it was a nice grounding question after a lot of theory. Roughly, the work splits into a few common tracks:

• Smart contract development - Writing the actual on-chain logic (commonly in Solidity for Ethereum-based chains), building things like token contracts, DeFi protocols, or NFT platforms.
• Protocol / core development - Working on the underlying blockchain software itself (consensus rules, networking, node software), a smaller, more specialized niche.
• Security auditing - Reviewing smart contracts for vulnerabilities before deployment, since bugs in deployed contracts are often impossible to patch after the fact and have led to some very expensive hacks.
• dApp / frontend development - Building the user-facing applications (wallets, exchanges, marketplaces) that interact with smart contracts, usually fairly standard web development plus a blockchain-connection layer.
• Tooling and infrastructure - Building the developer tools, indexers, and APIs that make all of the above easier to build on top of.

I gave a rough answer, but wanted to include a fuller version here for anyone who was curious.

If I'm honest, preparing a "beginner" talk made me more careful, not less, as trying to explain something simply exposes exactly which parts of your own understanding are still fuzzy. Several of these questions came from people who'd clearly thought about this more than I expected from a "beginners" audience, which was a genuinely good challenge.
Thanks to everyone who came, and especially to everyone who asked something hard. If you have thoughts, corrections, or want to argue with any of the above, I'd love to hear it.