McCoy

https://mccoy2016.me/

Bitcoin
NOSTR block 768722

Public Key

npub18y33vpqmudzm9wk9cnglgnrhqyu96c4l4tr59k2zw0gs5ep5a2kqjqx5t7

NIP-05 Address

Profile Code

nprofile1qqsrjgckqsd7x3djhtzuf505f3mszwzav2l6436zm9p885g2vs6w4tqp9fmhxue69uhhqun9d45h2mfwwpexjmtpdshxuet59ank7mrx94nxc6twwskhzatpwf685qgdwaehxw309ahx7uewd3hkcf7yzfp

Publishing to

premium.primal.net/golf-flint-quartz

nostr.sudocarlos.com/inbox

Author Public Key

npub18y33vpqmudzm9wk9cnglgnrhqyu96c4l4tr59k2zw0gs5ep5a2kqjqx5t7

Show more details

Last Notes

2026-07-22 12:19:20 UTC

https://docs.google.com/document/u/0/d/14DfMSVYBHTHIOmW32JTOR6BAP7AITbinvrhl8rJuvvc/mobilebasic?pli=1

2026-07-22 12:19:07 UTC

https://bitcoinmagazine.com/bitcoin-mining/ocean-mining-vp-jason-hughes-bip-110-on-track-to-fail-as-miner-signaling-stays-below-1

2026-07-22 11:25:02 UTC

https://bitcoinmagazine.com/bitcoin-mining/ocean-mining-vp-jason-hughes-bip-110-on-track-to-fail-as-miner-signaling-stays-below-1

2026-07-21 10:18:42 UTC

- reply

Any links to the details?
#nevent1q…5j98

2026-07-20 18:43:03 UTC

- reply

XAU could be ~$7-8k per oz by then..... about $200-250k per corn unit

2026-07-20 18:40:07 UTC

Bull doesn't start (=bear not over) until we capture 30oz......
https://blossom.primal.net/87f151bf0b24ac014b8ed6126a2be772f0b8fcf1eec5c656c41f339294a24b42.jpg

2026-07-20 10:54:25 UTC

Information _wants_ to be free
Valuable info will be
AI ponzi companies take note

2026-07-18 18:51:33 UTC

- reply

is merge mining and drivechains the same tech/proposal - HQ

2026-07-18 18:47:35 UTC

- reply

Then as its _failing_ then there would be a strong push for other solutions, including merge mining, right?

2026-07-18 18:17:30 UTC

Goin parabolic.... or not so much
https://blossom.primal.net/94d902f984c0cd35c7b001c73386ac4a7606bd0f61dce230adb4cd6427aa4fd0.jpg
https://blossom.primal.net/51bf957cae5d222dcbe8784dff5c2efd8c8375f287f0037849662388b8946952.jpg

2026-07-18 16:31:37 UTC

Oddly flat
https://blossom.primal.net/86e8dd53e79dadb7c9fcb441dc153ab21bb833c34aba5abe676df54f1a9b6734.jpg

2026-07-17 15:19:51 UTC

- reply

also i zapped and got a failed message

2026-07-17 15:18:18 UTC

- reply

Cool. Im just _a user of stuff_ + freak + humble stacker. i've managed to run both my own node and some lightning channels will start9 - novice. I was actually just unsure what tails relay did.

2026-07-17 15:03:19 UTC

- reply

Maple AI helping me understand.... it sourced RHR...🤣 LFG
https://blossom.primal.net/015b65be6c9a23143d2f1694c1670b48fe1131f1e06b9793edba1532a18bf3c1.jpg

2026-07-17 11:53:58 UTC

- reply

yo
#nevent1q…h5g6

2026-07-17 11:39:24 UTC

- reply

Is there a summary/ourline of exactly how to _close vulnerabilities_ without completely removing it?

2026-07-17 11:37:45 UTC

study it
https://blossom.primal.net/c9f3d2e3f3756ca198603e4ed02f179bdefb51648deb1e13c82818145c7d405e.jpg

2026-07-17 11:37:09 UTC

- reply

Rule 30
https://blossom.primal.net/c9f3d2e3f3756ca198603e4ed02f179bdefb51648deb1e13c82818145c7d405e.jpg

2026-07-17 11:35:04 UTC

- reply

buy the corn, now and 4-ever

2026-07-16 22:29:04 UTC

Here are the main ways people use Taproot’s multiple script paths, grouped by purpose:
**Recovery & Inheritance**
- **Social recovery:** A 2-of-3 main path, plus individual paths where each backup key works after a long timelock.
- **Inheritance / dead man’s switch:** A primary spending path now, plus a path to an heir’s key that only unlocks after, say, 1–2 years of inactivity.
- **Decaying multisig:** A 3-of-3 today, degrading to 2-of-3 after 6 months, then 1-of-3 after a year—so funds are never locked forever if keys are lost.
**Escrow & Dispute Resolution**
- **2-of-3 with arbitration:**
- Path A: Buyer + Seller (cooperative)
- Path B: Buyer + Arbiter (dispute)
- Path C: Seller + Arbiter (dispute)
You can add timelocks so the arbiter only matters if the two main parties deadlock for some period.
**Lightning Channels**
- **Key path:** Mutual close (cooperative, looks like a single-sig on-chain).
- **Script paths:** Force-close scenarios with revocation keys, HTLC success/timeout branches, and penalty clauses. Only the triggered branch is revealed; the channel state history stays hidden.
**Vaults**
- **Unvaulting path:** Requires a hot key + a timelock delay (e.g., 24 hours).
- **Cancel path:** During the delay, a cold key can sweep funds to a safety address.
- **Emergency path:** A deeply cold key can recall funds after a very long lock.
**Conditional Contracts**
- **HTLC variants / atomic swaps:** Different hashlocks or timelocks for different counterparties or chains.
- **Betting / oracles:** Path A pays Alice if oracle attests X; Path B pays Bob if oracle attests Y; Path C refunds after timeout if oracle never signs.
**Operational Security**
- **Hardware diversity:** One script path requires a Ledger + passphrase; another requires a Coldcard + passphrase; a third requires a seedless HSM. This avoids a single vendor vulnerability without revealing your full setup.
**Privacy & Decoy Patterns**
- **Dummy leaves:** Some wallets insert random decoy script leaves so an observer who sees one revealed script can’t infer how many *real* conditions exist.
The unifying theme is that **the key path handles the “happy/cooperative” case** (cheap, looks like single-sig), while **the script tree encodes every “what if” contingency**—and only the contingency that actually happens is ever exposed.

2026-07-16 21:51:52 UTC

- reply

yo
#nevent1q…mx55

2026-07-16 00:20:24 UTC

Maple AI :
The main controversy around Taproot's activation wasn't about Taproot itself — the upgrade was broadly popular — but about **how to decide when and whether to enforce it**. Specifically, the fight was over who ultimately controls Bitcoin's consensus rules: **miners or node operators**.
## The Core Divide: BIP9 vs. BIP8 (LOT=True)
The community split into two philosophical camps:
- **BIP9 / "LOT=False" (Miner-driven):** This approach let miners signal support, and if they didn't reach a threshold, the upgrade simply failed. Proponents argued this was safer and less disruptive — don't force a rule change unless miners clearly agree. Critics called this giving miners a **permanent veto** over a widely desired upgrade.
- **BIP8 with LOT=True (User-Activated Soft Fork / UASF):** This approach set a deadline by which miners had to signal; if they didn't, nodes would begin enforcing the new rules anyway, effectively forcing miners to follow or be orphaned off the network. Proponents argued this was necessary to prevent miner obstruction (citing the SegWit activation experience). Critics warned it could risk chain splits and network instability if not enough users actually ran the enforcing software.
## The Speedy Trial Compromise
After months of stalemate, developers Russell O'Connor and David Harding proposed **"Speedy Trial"** as a middle path:
- **Short trial period:** Miners got ~3 months to signal.
- **High bar:** 90% of blocks in a difficulty period had to signal to lock it in.
- **Fail-fast:** If miners didn't signal, the attempt died quickly — no automatic UASF fallback built into the Core client.
- **Long delay:** If locked in, activation waited ~6 months to give everyone time to upgrade.
This was essentially **BIP9-style miner signaling with a much shorter window**, designed to gauge actual miner support without embedding a mandatory UASF into Bitcoin Core's official release.
## Why It Was Controversial
- **UASF advocates were unhappy** because Speedy Trial removed the built-in "safety net" that would force activation if miners stalled. Some released alternate Bitcoin Core clients with LOT=True as a hedge.
- **Miner-veto critics** argued the process proved miners could still block things if they chose to, and that node operators had been sidelined.
- **Governance concerns:** The debate exposed how Bitcoin's decentralized development process can deadlock when there is no clear mechanism for resolving activation disputes.
## Outcome
Miners overwhelmingly signaled support, Taproot locked in, and activated successfully in **November 2021**. But the controversy left lingering questions about whether Speedy Trial was a pragmatic solution or a precedent that lets miners (or the status quo) stall future upgrades.

2026-07-15 20:28:52 UTC

- reply

friend's

2026-07-15 20:26:22 UTC

Large numbers + cryptography + computational proof via DA-POW
**SOLVED BOTH**
✅coin emission without seigniorage
✅coordination = consensus = time stamping

2026-07-15 20:13:56 UTC

BIP45 doesn’t introduce a new extended key prefix because:
It works with standard xpubs (or ypubs/zpubs if the multisig is wrapped in SegWit or native SegWit, though BIP45 itself was designed around P2SH).
It’s a layer above key format. The xpub/ypub/zpub tells you what address type the key produces; BIP45 tells you how multiple people agree on which addresses to produce.

2026-07-15 19:38:12 UTC

So much to be grateful for...
https://blossom.primal.net/a19fe2f0a4e5726b185f4f8b6dc2e5f0d1bd7847bb54767a919d2a05a468558a.jpg

2026-07-15 17:28:24 UTC

Blackrock assets (in fiat) are worth 10-12x total bitcoin total market cap...
Gold + AI stonks..... 100x ? 200x?.....
Rotation in coming

2026-07-15 16:52:35 UTC

- reply

Slow build. First asking, then understanding _what is money_?
After that, bitcoin is obvious.
The adage seems to hold: anyone who spends _adequate time_ (50 hrs? - 100 hrs ? or so) trying to understand bitcoin will get it.

2026-07-15 15:09:51 UTC

JP Morgan + Morgan Stanley with record Q2 profits
F-n bankers.
Opt out. Use a money they cannot control.

2026-07-14 20:43:02 UTC

- reply

I will have to think on that for a while....... Smaller blks size with higher fees would be on balance likely a good thing: you find out who really wants to transact or not..
Wolfram term/concept: irreducible. 🔥🔥
I'm sure you heard/read about his concept: _the ruliad_ 🤯

2026-07-14 18:33:52 UTC

- reply

For me its beverages: crisp, draft, beer, in a cool pub with a friend; warm cup of delicious coffee on a cloudy day reading a book; cold Gatorade, after an intense workout

2026-07-14 16:54:00 UTC

Everyone thinks their pet _topic_ explains the red/green candles: bip-110ers, Strategy dudes, suit-coiners, Clarity bros, Bent Oil watchers...
Who the hell knows what's gonna happen.
Same plan:
Work
Save
Stack
Wait

2026-07-14 12:48:56 UTC

Be aware freaks, be aware
https://blossom.primal.net/bce82da2ba03273c76e3afbec21cde65159ee85597df29e3f7a22a948c5a7ee0.jpg

2026-07-14 02:01:08 UTC

- reply

So post bip-110 (imagining it wins) everone runs knots with one maintainer?

2026-07-13 10:45:06 UTC

- reply

wtf
#nevent1q…x0vl

2026-07-12 21:13:13 UTC

https://open.spotify.com/episode/4d9A7b5LYNI4VL5TYRCkWF?
High signal + humor for the win

2026-07-12 13:27:41 UTC

- reply

Work. Stack. Chilln

2026-07-11 23:22:12 UTC

- reply

The level of hysterical alarm does not match the problem. We can fork to limit spam and even roll-back taproot down the road with a measured upgrade with more support ++ when we have multiple well supported clients that are mature. Right now the _crisis_ is manufactured: "CSAM is _eminent_ and will kill bitcoin" "Run it and you will be jailed."
And once forked all node software maintained by one guy - Luke.
No way

2026-07-11 17:40:42 UTC

I wonder how many of the BIP-110ers (maniacal plebs @nprofile…h34j)
actual run LN nodes.... or use bitcoin?
LN is helping scaling bitcoin and adds privacy. LN is actively being integrated into on-ramp/off-ramps, businesses, payment processers to the leagacy fiat system.
Channel rebalancing via submarine swaps is a key tool for channel management.
Taproot allows for better privacy + lower fees compared to P2WSH.
BIP-110 activation can (will?) invalidate this swap method.
Chance of unknown/inforseen issues of the 110-fork are definitely not zero.
Consensus should be hard to change. Very hard. Rationale needs to be compelling + clear to most plebs, not just a self anointed _maniacal_
few...

2026-07-11 16:54:13 UTC

BIP-110 does not break legacy or pre-existing vaults, but it does break the ability to create new Taproot Miniscript vaults that depend on OP_IF branches. If Taproot miniscript vaults/wallets or its users generate new vault addresses with unupdated software after activation (assumes BIP-110 fork wins), those funds are at risk of being temporarily unspendable.
BIP-110 authors disagree on necessity — some argue there is "no known use case" requiring OP_IF in Tapscript, implying the fee increase from using more leaves is acceptable. Critics counter that this ignores real-world vault architectures and security models that rely on composable script-level branching.
Bottom line:
For simple two-path vaults, yes — you can generally avoid OP_IF by using native Tapleaf disjunction. But some style institutional vaults often involve complex multi-party, time-locked, and threshold policies where decomposition either explodes past the 128-leaf limit or fragments the security model in ways that aren't practically deployable before the August 2026 activation deadline. So while a theoretical workaround exists, "just don't use OP_IF" is not a complete answer for every vault design.

2026-07-10 21:48:00 UTC

- reply

Best move: self custody and wait.

2026-07-10 21:24:53 UTC

Replay details via Maple AI:
Here’s exactly how it works:
**Before the split:**
Both chains share the identical blockchain history and the identical UTXO set. Your coins live at the same address, with the same txid and output index, on both the Core chain and the BIP-110 chain.
**You sign and broadcast on Core:**
You create a standard transaction spending your pre-fork UTXO to some new address. You sign it and broadcast it to the Core network. It gets mined into a Core block.
**The replay step:**
Because BIP-110 is a soft fork, a standard, valid Core transaction is *also* a valid BIP-110 transaction. The transaction format hasn’t changed. The signatures are valid. The inputs exist on both chains.
So anyone — it could be the recipient, a miner, or literally any observer — can take the raw transaction hex from the Core block (or mempool), and just re-broadcast it to the BIP-110 network. BIP-110 nodes see it and say, “Yep, that’s a valid transaction spending a valid UTXO,” and mine it into a BIP-110 block.
**The result:**
Your UTXO moves to the destination address on *both* chains simultaneously. You never intended to move it on BIP-110, but it moved anyway because the transaction was valid there too.
**Why this matters:**
If you were trying to sell your “BIP-110 coins” to an exchange while keeping your “Core coins,” the replay means both get sent to the exchange. Or if you were trying to split your coins by sending them to different addresses on each chain, replay undoes that — the same transaction executes on both sides.
**The exception:**
This only works for pre-fork UTXOs. If a UTXO was created *after* the fork on only one chain (like a coinbase reward, or a transaction spending a post-fork UTXO), it can’t be replayed because it doesn’t exist on the other chain.
That’s why, without explicit replay protection, a chain split is so messy: every pre-fork coin is entangled across both chains until you deliberately “taint” or split them using techniques like mixing with coinbase outputs or `nLocktime` tricks.

2026-07-10 16:18:01 UTC

2026-07-10 15:57:00 UTC

2026-07-10 02:31:17 UTC

- reply

This assumes: 1.) exchanges will list both coins 2.) you will know with certainty which fork will win
Exchanges will likely not list - easier/safer to just sit it out or perhaps _declare_ one coin the _winner_
Other option: move all coins to self custody cold storage + do nothing

2026-07-09 22:50:21 UTC

- reply

The post arrow doesn't show up

2026-07-09 22:49:02 UTC

@npub16c0…6nvr
seems to be a bug when I try to respond to notes. Can't post.
https://blossom.primal.net/98aae3748a4d6dc8fedc9fcad2e268ec266d9d4e9bdfa91c384dd52377b7eca4.png

2026-07-09 22:45:34 UTC

- reply

Fails for sure.
Sets the stage to softfork out large op_returns and rollback/edit taproot

2026-07-09 21:53:07 UTC

- reply

What about the base, it looks like a ceramic

2026-07-09 21:28:49 UTC

contentious soft fork, what will exchanges do. Maple AI:
Yes, exactly. Listing both sides and letting them trade against each other is the only way to produce a honest economic signal. If exchanges do that, the market immediately tells miners which chain is more valuable, and miners switch to the higher-revenue chain almost mechanically.
But here is the reality: exchanges usually do not want to provide that clarity.
Why Exchanges Avoid Listing Both
1. Operational and legal risk
A contentious fork means replay attacks, address format confusion, deposit/withdrawal exploits, and double-spend attempts. Supporting two "Bitcoins" simultaneously requires engineering work, legal review, and customer support chaos. Most exchanges would rather avoid that entirely.
2. Brand and reputational risk
An exchange that lists a forked coin implicitly legitimizes it as a real asset. Many exchanges do not want to be seen as endorsing what they view as an attack on Bitcoin, or conversely, they do not want to anger the community by appearing to validate a contentious rule change.
3. They prefer to act as kingmakers
If an exchange pre-announces "we will only recognize the non-signaling chain as BTC," they have effectively short-circuited the market signal. Miners now know that signaling for BIP-110 might win the technical war but lose the economic one — their coinbase rewards will not be spendable at the exchange where they pay bills. This lets exchanges pick winners without ever allowing price discovery.
What Actually Happens
In practice, most major exchanges will likely:
Halt deposits/withdrawals during the activation window
Wait to see which chain accumulates more proof-of-work or which one their counterparties recognize
Eventually resume trading on one side as "BTC"
Maybe, grudgingly, credit the other chain as a separate asset weeks later if it survives
This is what happened with BCH and BSV. The delay and confusion actually obscured the signal rather than clarifying it.
Why Your Point Matters
If exchanges did list both immediately — call them BTC-filter and BTC-spam or whatever — the community would see within hours which one the market values more. Hashrate would follow the price within days. The uncertainty would resolve quickly through actual price discovery instead of Twitter warfare.
So yes, listing both coins would make the signal far clearer. The fact that exchanges resist doing so is precisely what makes contentious forks so dangerous — the market is prevented from speaking clearly, and politics fills the void.

2026-07-09 13:19:23 UTC

Two numbers:
✅21 million fixed by math, energy and human incentives
✅39.4 trillion unbounded by math and human incentives
https://blossom.primal.net/c29692939e72a03126d340bd39e259c48ab003ae70100f035150f1dd6770d5d3.jpg

2026-07-09 13:16:04 UTC

2026-07-09 13:12:09 UTC

https://blossom.primal.net/200b4e61aed3f33e8a1af93455279415235557f80564bf43fe888715f525ebab.jpg

2026-07-09 01:53:44 UTC

- reply

The relationship between bitcoin versus regulators / law-enforcement, is far more nuanced than saying:
"If somebody does something illegal on Bitcoin, then unbounded criminal liability attaches to everyone who's running a node or mining bitcoin."

2026-07-09 01:50:00 UTC

- reply

More like you are literally sending a string of 1s and 0s, embeded with other similar 1s/0s that you might not even know about and cant easily decipher/look-at.
or
someone scribed out a horrible immoral phrase in morse-code on the $100 bill you are handing to the teller

2026-07-08 21:44:36 UTC

Maple AI weighs in
**BIP-110: Why Now?**
The urgency around BIP-110 in 2025–2026 bears little resemblance to the 2015–2017 era. That period saw real, contentious fork attempts—Bitcoin XT, Classic, and Unlimited all failed to gain economic support, and the New York Agreement emerged only after miner-driven alternatives had collapsed. It was a genuine fight over consensus and chain splits, with SegWit eventually adopted because it had broad technical backing.
Today's situation is different. There are no corporate or miner-led fork threats. The concern is chain spam—users parking data on-chain under borderline financial pretexts. Yet mempools are largely empty, fees remain low, and permissionless transactions work fine. The perceived threat rests on hypothetical scenarios: the possibility of harmful data being stored permanently, with a puzzling distinction drawn between discrete chunks and continuous streams. Neither feels like an active crisis.
If the goal is limiting arbitrary data, an 83-byte OP_RETURN restriction already addresses much of this and can be used now. The heavier lift—building consensus to modify or remove Taproot's data-carrying mechanisms—is worth doing through deliberate coordination.
Rushing BIP-110 on these grounds feels premature.

2026-07-08 21:35:04 UTC

- reply

Only works if both forks survive long enough to be listed on exchanges + exchanges support them.
Also how will you know which fork will win? You wont with 100% certainty. So, pick your fork-support wisely....
Another strategy: 1.) all coins in self custody, cold storage, then...... 2.) do nothing - act like your in a coma for a year or so

2026-07-08 13:13:39 UTC

- reply

Near boomer here: Alby via start9. Works. Use LN to zap and sometimes pay for good stuff, like robosats invoice/deposit

2026-07-07 21:37:09 UTC

Yes. In Bitcoin Core 30.0, you can set `-datacarriersize=83` in your `bitcoin.conf` or via command line.
However, be aware of an important semantic change in v30.0:
- **Before v30.0:** `-datacarriersize=83` meant each individual OP_RETURN output could be up to 83 bytes (and only one OP_RETURN per transaction was allowed).
- **In v30.0:** The same setting limits the **aggregate total** of **all** OP_RETURN outputs in a transaction to 83 bytes. Multiple OP_RETURN outputs are now permitted, but their combined data must fit within your limit.
So while setting it to 83 reverts toward the old behavior, it is technically stricter than before because the limit is shared across all OP_RETURN outputs in a transaction rather than applying per output.
The default in v30.0 is `100000` (100,000 bytes aggregate), which is effectively unrestricted for practical purposes. If you want to enforce tight data carrier limits, setting it to 83 is the correct way to approximate the pre-v30.0 policy.

2026-07-07 16:16:27 UTC

- reply

Assuming the _attack_ is: mining/extending on a chain with BIP-110 incompatible blocks/transactions?
Meanwhile..... the real _attack_ will be the CSAM *monitors* will flag only continuous data that can be interpreted as an image from this CSAM chain, and broadcast to the _world_ that anyone running a node, mining, developing on bitcoin should be jailed

2026-07-06 01:18:15 UTC

- reply

IDK..... intent matters...
sending or saving a string ones&zeros that you dont know is there, dont want, cant *read*, wont read is not clearly a crime

2026-07-02 01:13:16 UTC

- reply

The way it doesnt fail is NGU. NGU equals adoption

2026-07-02 00:44:19 UTC

- reply

LFG

2026-07-02 00:36:50 UTC

- reply

my bad - blood brothers

2026-07-02 00:34:14 UTC

US Soccer team should have a free-safety like badass who just kickass during the game, never fakes a fall, muscules through every play, runs, hustles
... like Ed Reed

2026-07-02 00:26:10 UTC

- reply

settle down clanker

2026-07-02 00:24:12 UTC

Howard Lutnick sitting with Fifa pres

2026-07-01 16:39:56 UTC

Foreword
By Nassim Nicholas Taleb
January 22, 2018
Let us follow the logic of things from the beginning. Or, rather, from the end: modern times.
We are, as I am writing these lines, witnessing a complete riot against some class of experts, in domains that are too difficult for us to understand, such as macroeconomic reality, and in which not only is the expert not an expert, but he doesn't know it. That previous Federal Reserve bosses Greenspan and Bernanke had little grasp of empirical reality is something we only discovered too late: one can macroBS longer than microBS, which is why we need to be careful of whom to endow with centralized macro decisions.
What makes it worse is that all central banks operated under the same model, making it a perfect monoculture.
In complex domains, expertise doesn't concentrate: under organic reality, things work in a distributed way, as F. A. Hayek has convincingly demonstrated. But Hayek used the notion of distributed knowledge. Well, it looks like we do not even need the "knowledge" part for things to work well. Nor do we need individual rationality. All we need is structure.
It doesn't mean all participants have a democratic share in decisions. One motivated participant can disproportionately move the needle (what I have studied as the asymmetry of the minority rule). But every participant has the option to be that player.
Somehow, under scale transformation, a miraculous effect emerges: rational markets do not require any individual trader to be rational. In fact they work well under zero intelligence—a zero-intelligence crowd, under the right design, works better than a Soviet-style management composed of maximally intelligent humans.
Which is why Bitcoin is an excellent idea. It fulfills the needs of the complex system, not because it is a cryptocurrency, but precisely because it has no owner, no authority that can decide on its fate. It is owned by the crowd, its users. And it now has a track record of several years, enough for it to be an animal in its own right. For other cryptocurrencies to compete, they need to have such a Hayekian property.
Bitcoin is a currency without a government. But, one may ask, didn't we have gold, silver, and other metals, another class of currencies without a government? Not quite. When you trade gold, you trade "loco" Hong Kong and end up receiving a claim on a stock there, which you might need to move to New Jersey. Banks control the custodian game and governments control banks (or, rather, bankers and government officials are, to be polite, tight together). So Bitcoin has a huge advantage over gold in transactions: clearance does not require a specific custodian. No government can control what code you have in your head.
Finally, Bitcoin will go through hiccups. It may fail; but then it will be easily reinvented as we now know how it works. In its present state, it may not be convenient for transactions, not good enough to buy your decaffeinated espresso macchiato at your local virtue-signaling coffee chain. It may be too volatile to be a currency for now. But it is the first organic currency. But its mere existence is an insurance policy that will remind governments that the last object the establishment could control, namely, the currency, is no longer their monopoly. This gives us, the crowd, an insurance policy against an Orwellian future.
Nassim Nicholas Taleb
January 22, 2018

2026-07-01 14:26:09 UTC

Hold cash to guard against future uncertainty
Bitcoin is the best cash, ...... by miles
Next best: C-Notes

2026-07-01 12:47:53 UTC

"I think we should be a little bit more humble in claiming because we have some technical knowledge about something, we can predict human behavior. And I'll give you another good example, actually, because nothing has actually gone in Bitcoin's history. Nothing has actually gone exactly the way anybody has predicted it would. And I'll tell you how we could have lost the block size war and not gotten Segwit. And I promise you there's not a soul on earth who could have told you that this definitely wasn't going to happen. We were betting and got lucky on the ignorance of the big blockers in how Bitcoin worked because they could have stopped Segwit. And if you tell me, oh, we had support for Segwit and they weren't belligerent enough, that's bullshit. You don't remember what it was like talking to them. They were going to slit somebody's throat over this issue. They were stopping Segwit and they were refusing to give Segwit specifically for the purpose of getting their hard fork. They didn't give a shit about what was good for the network. They wanted their way. Had they understood how nodes worked and had they understood how the dynamics of the soft fork, they could have done a user rejected soft fork of SegWit activation and SegWit would not have won. The UASF would have failed if they had forced SegWit off the network from the Bcashers rather than them actually splitting off into their own fork. They wouldn't have gotten their fork because that requires extremely high and broad consensus. But they could have stopped a soft fork because that only requires enough people for inertia to land on the people who did not update. We got lucky because they didn't understand how nodes worked. In fact, they went so belligerent, they were so angry about the idea that nodes could stop them from getting their hard fork, that they literally, I think just out of pure belligerence, adopted the policy that nodes don't matter at all, and then started preaching that mantra that your node doesn't do anything. And that was their ultimate failure. If they had just accepted and thought about the nuance of what a node does and how they could have actually enforced their power even without minor hash rate, they could have stopped Segwit - and nobody would have known, you cannot predict whether or not they were going to do that. We did not know the outcome. It was a gamble. We were playing chicken. And when you play chicken and claim what the outcome is going to be, you're betting on what a person is going to do and you don't know it. And it's not an arbitrary fence-sitter, it's not a, those are unknown unknowns, it's literally the area in which nobody can know."
".....That's exactly why I am a fence sitter. If anybody wants to call it, I don't give a shit anymore. I'm literally so sick of everybody telling me exactly what it's going to be and then playing this like silence is violence bullshit. Like I have to pick a side. If I don't think either one of you right are right, I'm not going to pick one of you. "
@nprofile…qpv4

2026-07-01 02:55:38 UTC

- reply

fixed transaction maleability to enable LN.... thats about it

2026-06-30 23:33:10 UTC

From Maple AI: RDTS:
**RDTS** stands for **Reduced Data Temporary Softfork** — a proposed Bitcoin network upgrade (also associated with **BIP-110**).
**What it does**
It would temporarily impose strict consensus-level limits on how much arbitrary data can be stored in Bitcoin transactions. Key restrictions include:
- `scriptPubKeys` capped at **34 bytes**
- `OP_RETURN` outputs capped at **83 bytes**
- Limits on Taproot control blocks and certain Tapscript logic
- Banning undefined witness versions
**Purpose**
Proponents argue it’s a short-term protective measure to:
- Reduce blockchain bloat and node storage burdens
- Preserve Bitcoin’s monetary utility
- Mitigate legal risks for node operators (e.g., concerns about immutable non-financial data on-chain)
**Deployment**
- Designed to last roughly **one year**
- Uses a modified BIP9 activation with a **55% miner signaling threshold**
- Target mandatory lock-in around **September 2026**
**Controversy**
Critics (including developer **Mononaut** from mempool.space) warn it could:
- Break existing applications
- Invalidate over 54,000 historical witness outputs
- Accidentally disable legitimate transaction types like P2PK and P2MS
Some groups (e.g., Lightning Network Liquidity) have already moved to compatible implementations like Bitcoin Knots in anticipation of the upgrade.

2026-06-30 16:59:02 UTC

- reply

this thing's cool. But doesn't the stimulator assume that there is a ratio of hash rate: say 55% verse 45% and that ratio stays fixed throughout the simulation? This may not be how the real world works. Miners may switch as it's playing out.... right?

2026-06-28 20:48:07 UTC

- reply

so if im running core 29.0 Op_return DCS at 83 bytes, and bip-110 activates with overwhelming support/hash, then my node is not in consensus, right?

2026-06-28 20:32:37 UTC

- reply

forks by definition are not backwards compatible

2026-06-28 01:40:02 UTC

- reply

kill shot, really? that easy to kill?
#nevent1q…ke3u

2026-06-28 01:22:13 UTC

They are spamming the network........meanwhile:
https://blossom.primal.net/1bd14353c07d6b41552301c241d6c398459a90d3492c661a25220b9fd4388511.jpg

2026-06-27 15:47:20 UTC

Lots of noise.
Same plan, same questions:
✅work, produce value, always
✅ask yourself will a neutral digital sound money beat the next best money?
✅current WRC = USD/t-bills/bonds: can a debit-base monetary fiat system beat BTC in the digital age?

2026-06-25 17:59:13 UTC

"It is an error to say that Core removed the ability for nodes to control their mempool policy regarding OP_RETURN and that Core removed the OP_RETURN limit at the protocol level."
https://stacker.news/items/1509743

2026-06-25 15:26:08 UTC

- reply

Changing consensus should be very very hard.
Taproot upgrade was in retrospect probably not the right move.
BIP-110 or the version - post one year - will also likely be problematic for issues that are currently hard to see/unforeseen.
Default should be no change.
Pushing this as an *emergency* or even an *urgency* is not based in facts and IMHO will be why BIP-110 fails.

2026-06-25 15:17:38 UTC

- reply

Help me then: how is this wrong?
--->
Luke or a small team of devs could *push through a consensus change* in knots that they are *sure* is best for the network. Forces users to follow without choice: after two years only the newest version works, right?

2026-06-25 14:58:05 UTC

- reply

No. I dont support Core version 30.0, by running 29.0.
Luke or a small team of devs could *push through a consensus change* in knots that they are *sure* is best for the network. Forces users to follow without choice.

2026-06-25 14:31:09 UTC

- reply

Per Maple AI, kimi k2.6:
"Yes, BIP-110 would constrain certain Taproot scripts, and under specific circumstances it could render some UTXOs unspendable.
**How it constrains Taproot scripts**
BIP-110 proposes (among other things) to make the following invalid in tapscripts for blocks mined after activation:
- **`OP_IF` and `OP_NOTIF`**: These opcodes would be disallowed entirely in tapscript, even in branches that are not executed.
- **Large control blocks**: Taproot control blocks larger than 257 bytes would be invalid — this effectively caps the Taptree at 128 script leaves.
- **Large data pushes**: Data pushes greater than 256 bytes would be invalid.
**Could this make UTXOs unspendable?**
Yes, but primarily for a specific edge case. BIP-110 includes a **grandfather clause**: UTXOs created *before* activation are exempt and can still be spent using old scripts. However, this protection does not fully cover:
- **Pre-signed or timelocked transactions** created before activation but broadcast *after* activation.
- UTXOs that rely **solely** on a now-invalidated script path (e.g., one using `OP_IF`) and have no alternative valid spending path (no key-path spend, no other valid tapleaf).
If a Taproot output was constructed to force spending through a script leaf that BIP-110 invalidates, and that transaction is only revealed after activation, the consensus rules would reject the spend. With no valid path remaining, those funds would become unspendable for the duration of the softfork.
This has led to criticism that the proposal risks a form of *de facto confiscation* for certain complex Taproot contracts, even though standard pre-activation UTXOs are technically grandfathered."

2026-06-25 14:23:39 UTC

- reply

With knots not working after two years, that is essentially forcing users to automatically upgrade.
Not true for core. I can keep running 29.0, for as long as I want.

2026-06-25 11:23:25 UTC

- reply

Does BIP-110 *band* scripts that in part are used for financial transactions?
Why?
Does a given Knots version stop working after two years?
Why?

2026-06-25 00:51:09 UTC

- reply

The proposed solution seems worse to me than the problem.
Problem(s): nonmonetary data on chain; TapRoot seems to have introduced unknown, unknowns
Proposed solution: temp softfork, limiting rules with only 55% signal threshold; with a very small client dev team maintaining code; some supporters claiming its an *emergency*, and even hinting at legal threats to devs/miners/others who don't join their team

2026-06-24 17:13:38 UTC

- reply

running 29.0

2026-06-24 17:10:28 UTC

- reply

and zappn

2026-06-24 16:59:47 UTC

Out here grinding
Cuck buck price agnostic
I wont use their money

2026-06-22 20:01:59 UTC

- reply

send your clanker on a mission to save sparrow on mac

2026-06-12 15:29:58 UTC

- reply

Buy and hold the real thing, not that paper shit

2026-06-12 15:23:11 UTC

Saving in hard money without permission for my future self.
Meanwhile...
Degens buying a tokenize IPO promise of a paper promise, of a space/AI datacenter product that is at best decades away
🤡 show

2026-06-12 15:11:39 UTC

SPCX *insiders* will be dumping on normies for months/years
It has arrived:
IPO Rug Summer

2026-06-07 15:33:31 UTC

- reply

My list, 1986:
Peter Gabriel – So
Beastie Boys – Licensed to Ill
Talking Heads – True Stories
Van Halen – 5150
Bruce Springsteen – Live/1975–85
Cyndi Lauper – True Colors

2026-06-06 22:17:22 UTC

- reply

Buying April 2021 at $50-60k anticipating god candles.... it been a bit rough
https://blossom.primal.net/d3e264b5605ae33d3b2d44f5f0ad36b7423a6ec98930adc62f9bf0aaae4ce987.jpg

2026-06-05 21:07:59 UTC

- reply

LFG
Bitcoin Optech summarized proposals to make BIP324 transport encryption quantum secure and standardize QR-based signing payloads for miniscript wallets.
-- The work targets wallet interoperability and node privacy before quantum attacks are practical, giving operators and developers a clearer protocol migration path without urgent consensus changes.

2026-06-05 21:04:34 UTC

- reply

Remember: at the time of the early COVID printing virtually all were *onboard* ... only later did the postmortem revealed the truth, but early on many/most were scared of dying + fear of economic collapse
Same playing out now... AI promise has captured the zeitgeist, they can/will print without backlash

2026-06-05 20:58:52 UTC

- reply

Massive printing to support AI:
✅"existential threat"
✅cant let China win
✅prevent terrorist from winning
...and for good measure...
✅save the children

2026-06-04 02:10:21 UTC

- reply

Yes, two key factors:
✅merchants have to produce high quality stuff
+
✅refuse fiat

2026-06-02 22:45:35 UTC

Submarine Swaps
🔥🔥🔥
Example — Loop In (you need to receive more):
You have on-chain bitcoin but your Lightning channel is full on your side. You and a swap service agree on a secret hash H (you know the preimage R).
You lock on-chain BTC in an HTLC: “pay the service if they show R by block X, otherwise refund me.”
The service routes a Lightning payment to you locked by the same hash H. To claim that Lightning payment, you reveal R.
The service sees R and claims your on-chain BTC.
Result: You gained inbound Lightning liquidity; the service got your on-chain BTC (minus fees). If anything fails, the timeouts ensure everyone gets their funds back — no one can steal.
In Short
Submarine swaps are a trustless bridge between on-chain and Lightning bitcoin. They let you buy inbound liquidity or cash out to on-chain without closing your channels, using the same atomic HTLC logic that makes Lightning itself secure.