Register and share your invite link to earn from video plays and referrals.

Vortex | BIP448
@theonevortex
Former host of The Bitcoin News Show. Creator of Bitcoin Is. And that is enough.
1 Following    53.8K Followers
> Yep. And it’s centralized and captured with pure fiat governance and culture. Nope. Bitcoin just didn't care about your virtue signaling. Get over it. > I have no interest in the narratives about what constitutes "real" Bitcoin. Yet you keep talking about it every day on twitter. > I’ve lost faith in BTC’s potential to serve as a technology You never even understood it in the first place. > then that’s where I’ll focus my energy. It’s about the IDEA, not the name. As we've said for nearly 4 years, enjoy your shitcoin. > I put my energy and attention where I have faith and conviction. So talking nonsense on twitter all day, got it.
Show more
@ProofOfCash @Fonta1n3 @thechoderogan Hilarious watching these 110 people repeat the same false narratives over and over even when presented with objective on-chain data.
@bensig > that small policy change damaged Bitcoin’s “social layer.” Nah, it just made a bunch of non technical virtue signaling newbies learn more about what bitcoin is, bitcoin is fuck you money and you don't get to tell others what they can or cant' do with it. Welcome to bitcoin.
Show more
@DrStarHeartsong @matters_btc @adam3us @grok @NickSzabo4 Your points are technically inaccurate, your comments on "purpose" are nonsensical and don't apply, you have no idea what you're talking about and refuse to do research and learn. This is why signaling is at less than 1% because people like you are who 110 is sending.
Show more
@giacomozucco @L0RINC @janrothen @TheGuySwann @LynAldenContact @adam3us @stephanlivera No. Category error. Existing rules verify PROPERTY as in signatures proving ownership, they're content blind & apply identically to every byte, BIP110's rules inspect data SHAPE to block certain content from existing. Verifying ownership isn't censorship, blocking expression is.
Show more
@flaming_hodl I'm neither a suit or an influencer and I am against 110.
@pete_rizzo_ @giacomozucco > We should support imo the right of anyone to write and maintain Bitcoin compatible software Right, until they bundle it with a hostile SF and its creator does a 3+ year smear campaign on core developers, at that point it's time to stop supporting it.
Show more
> "Up to 20% of nodes are already running enforcement software." No. Knots has been flat at around ~20% for many months and signaling is at around ~1% or less. Running Knots doesn't mean enforcing BIP-110, understand the difference. > "BIP 110 enforcement nodes begin building their chain exclusively on top of blocks that signal compliance." and "The network's BIP 110 enforcement nodes perceive them as canonical (longest, valid chain)." Wrong. Nodes validate and relay, they don't build anything. The chain enforcement nodes would follow only has whatever hashrate actually signals behind it, so a first mover with 5% of hashrate produces a chain running at 5% speed with no retarget for months. "Canonical" to a few thousand Knots nodes with no economic weight isn't canonical to anything that matters, and below the 55% threshold the outcome is a minority chain, not a protocol change, which will fork itself off almost immediately. > "Those blocks don't propagate as cleanly." Wrong. Non-signaling blocks propagate fine through the 92-98% of nodes that don't enforce, and miner-to-miner block relay happens over dedicated relay networks anyway, so orphan risk from a single-digit slice of listening nodes is negligible. > "Miners with flexibility start routing hashrate to the pool with the highest probability of their blocks being added to the chain" and "blocks there are guaranteed to be valid everywhere and accepted by 100% of the nodes in the network." Wrong. Hashers route on payout per hash, not node acceptance. A pool committed to BIP-110 rules forgoes data transaction fees on the majority chain so its payout is lower, and acceptance by an economically empty partition earns zero extra sats. The incentive points away from the signaling pool, not toward it. > "Current estimates peg transaction fees at around 15% of miner revenue in normal periods." versus "a declining revenue stream that's already heading toward zero anyway. There's nothing to lose by signaling." Both can't be true. If data fees are meaningful the first mover eats a real cost alone while competitors keep collecting, and if they're zero the coordination premium evaporates along with the stated urgency for the fork itself. > "if a pool signals first, they capture the coordination premium. They become the obvious, safe pool." and "the pool that moves first wins the coordination game." Already tested and failed. Barefoot Mining via Ocean produced the first signaling block on March 1, 2026 and no major pool has followed, with no observable hashrate migration toward Ocean. SegWit in 2017 activated because the economic majority backed BIP 148, and here the economic weight is on the other side with Saylor and Back publicly opposed and Core not endorsing. In this signaling period segwit was well above 30% and 110 is around ~1%. In summary this post pretty much gets everything backwards. Nodes don't build chains, miners do, and hashers chase payout not node approval. A pool that signals first isn't capturing a premium, it's taking a unilateral fee cut for a minority chain with no economic weight. Ocean tried it in March. Nobody followed. Consensus has already spoken, 110 is DOA.
Show more
@giacomozucco Giacomo you must have seen this misconception coming with your constant and vocal support of Knots on twitter?
> What Lyn seems to be missing is that BIP110 is not a protocol change, but a correction to fix the mess that Core has done. We are getting Bitcoin to be how it was in 2022. 100% false. 110 introduces A NEW consensus rule that never existed before, in addition to that it has a ton of technical issues that I outline here: So with zero technical consensus and less than 1% signaling weeks before activation it's clearly DOA.
Show more
@CJABTC @cguida6 110 is nothing more than a power grab, it has a huge amount of technical issues that I outline here that the 110 side has yet to debunk:
Your latest article was once again easily debunked since you clearly have only an extremely basic understanding of how bitcoin works: > Vortex claims above “[BIP]110 does not stop or slow down any spam”. This is such a disgusting and blatant lie that the data spam apologist camp keeps repeating over and over again. This is 100% false, literally every single spam app has updated their software to be 110 compliant. > BIP110 works as a charm and that is proven on at least 2 places. Not even a little bit accurate. You cited two sources as proof and they contradict each other on the exact claim you're making. Source 1 claims zero false positives, 100% of Rule 7 catches were inscriptions, "zero collateral damage." Source 2 says 81.1% of blocked transactions classify as spam. That means by your own second source roughly 19% of what BIP-110 blocks does NOT classify as spam, and across 1.2 billion transactions that is an enormous absolute number of non-spam transactions caught. A 0% collateral claim and a ~19% collateral claim aren't corroboration, they're a methodological dispute you mistook for consensus. The block weight numbers disagree too. Source 1 says 36% of block space filtered, Source 2 says 4.93% of post-inscription block weight. And note what 4.93% actually means: the transactions BIP-110 targets are under 5% of block weight. That's the emergency justifying Bitcoin's first consensus downgrade. More fundamentally, both are backtests. They replay transactions crafted before the rules existed and count matches. Of course a filter catches the patterns it was written against. A BIP-110-compliant data embedding transaction already exists, verified on regtest against the BIP-110 implementation itself with a published reproducible script, and the compliant version came out LARGER with the data pushed into outputs nodes store in the UTXO set forever instead of prunable OP_RETURN. That is what "does not stop or slow down spam" means. The data still goes in, bigger and less prunable. Your backtests don't touch that argument and your sources can't even agree with each other. > Soft forks like BIP110 historically always involved lots of debating, Yes and they also involve lots of testing which 110 has not gone through, not only that but they already had to request the help of several core developers on several occasions due to the incompetence of dathom who essentially vibe coded the entire client. > Bitcoin Core’s highly controversial data spam-friendly direction with their October 2025 v30 release. Bitcoin core didn't take a spam-friendly direction, this is a lie, they simply changed a relay policy filter default that anyone can configure on their own node. > And this poor lad called Vortex apparently still hasn’t come across my previous article “Stop Being Retarded, Bitcoiners, Eat A Bag Of Dicks”. Not only did I read the terrible writing I replied BOTH on twitter and medium with the only comment on the page, you can read right? > To add, the as we speak still low initial miner signaling (~1% in recent days, against ~15% full nodes signaling) shows that BIP110 is not steamrolling the Bitcoin network Yes because literally nobody is signaling for this terrible software, it's still less than 1%, it literally never even hit 1% signaling yet despite activation only being weeks away. > This is, of course, backwards. No actually, You're equivocating on "centralize" and the argument dies without it. Rich users bidding up an open fee auction is not market centralization, anyone can outbid them, that's the neutral market working. Centralization means template construction, fee capture, and transaction access concentrating in fewer hands. Filters demonstrably cause that: filtered demand routes out-of-band to direct miner submission (Slipstream exists for exactly this reason), which advantages large miners and starves small pools on public relay. Pulling that flow back into the public mempool was the stated rationale for Core v30's OP_RETURN change. Cause and effect on record, opposite direction to yours. BIP-110 adds a second vector: 55% miner signaling makes miners the arbiters of which paying demand counts as legitimate. Consensus-level legitimacy gatekeeping of demand is blockspace market centralization by definition. Also, OP_RETURN is prunable. The filter's demonstrated displacement effect pushes data into UTXO set outputs your node stores forever, ~95% more permanent burden for ~11% more spammer fees. Your node runner argument is an argument against the filter. > BIP110 restores the balance that existed up till early 2023 by enforcing tighter limits on new UTXOs/outputs (scriptPubKeys ≤34 bytes except OP_RETURN ≤83 bytes; data pushes/witness items ≤256 bytes) while grandfathering pre-activation UTXOs 100% false. Point to the block height where a 34-byte scriptPubKey cap or a 256-byte witness element limit was consensus. You can't, because they never existed. Consensus allows 10,000-byte scripts and 520-byte elements, and OP_RETURN size was always relay policy. "Restores the balance" means inventing rules Bitcoin never had and calling it restoration. What existed pre-2023 was an absence of demand, not a ruleset. Your own historical precedent is the strongest evidence against you. 2014: Core cut OP_RETURN standardness to 40 bytes to discourage embedding, Counterparty moved its data into bare multisig, UTXO set bloat got worse, and OP_RETURN was kept as harm reduction because devs concluded you can only steer embedding, not stop it. Same displacement the BIP-110-compliant demo just showed again a decade later. Satoshi never once used consensus rules to filter content. Relay defaults and persuasion, that's it, from the guy who put the Times headline in the genesis block. You're citing him for a mechanism he never touched. And "subsidised storage" is backwards: the witness discount prices data by its real node cost, output data burdens the UTXO set forever while witness data doesn't. Inscribers pay full market rate under correct pricing. Your rules push data back into the expensive place. > On piling multiple systems/data into one chain (BitDNS discussion, December 10, 2010 Real quotes, wrong conclusion. All three show Satoshi declining to add features or telling other systems to use separate chains. Zero of them show him forbidding data via consensus, and your own third quote contains his actual remedy: "a separate system parallel to the bitcoin network." Build elsewhere is not make-invalid. Here's the fact that settles it: Satoshi had unilateral consensus power and used it, disabling opcodes in 2010 over security bugs, during the same period as your quotes. He never aimed it at data. He also documented his anti-spam mechanism explicitly: transaction fees as the flooding defense. Satoshi's answer to unwanted transactions was pricing, not filtering. You're quoting the man whose revealed preferences support my argument. And the BitDNS thread you cite ends with Satoshi proposing merged mining, which embeds other chains' commitments into Bitcoin's coinbase. His solution to "don't pile systems into one chain" was a form of data embedding. Your quote 2 describes users limiting the SIZE of the chain, a uniform limit on everyone. That maps to a block weight reduction soft fork, not to a filter that keeps blocks the same size while selecting allowed byte patterns. Stand on Satoshi consistently or don't stand on him at all. > LN-Symmetry (Eltoo) and related covenant improvements are advanced Layer 2 features. OP_IF in a tapscript is a spending condition, not "arbitrary data." Vaults, BitVM and ln-symmetry ARE the on-chain enforcement, and Lightning only keeps data off-chain because those scripts stay valid, so reclassifying money logic as data to excuse filtering it just proves the filter can't tell the difference. And "temporary" has no precedent because there has never been an expiring consensus rule in Bitcoin's history, so name one. The reassessment clause is circular since legitimate contracts can't "emerge" while consensus-invalid, and a rule renewable yearly by 55% signaling isn't a pause, it's an indefinite freeze with annual review that nobody funds multi-year R&D under. > This is similar to the previous point: we are talking about temporary restrictions on certain tapscript patterns (e.g., OP_IF/NOTIF in executed contexts and large structures). Your sources don't even agree here: one claims zero false positives precisely because no legitimate tapscript OP_IF contracts exist on mainnet, and now wallets "may need updates," both can't be true. And "may need updates" is what breakage is called by the side that caused it, because when consensus invalidates scripts that working software emits that's the definition of breaking compatibility. The tapleaf workaround isn't free either since flattening mixed threshold policies into separate leaves blows up leaf count, depth and control block size, which BIP110 also limits by your own account, so one rule pushes wallets into the structure another rule punishes. Grandfathering only covers coins already on-chain, not vault and recovery protocols whose pre-signed continuation transactions create new outputs, and since deleting keys after pre-signing IS the vault security model those setups can't adapt. Consensus changes ship with tooling and test vectors settled up front like Taproot did, not with "guidance will be provided." > First of all, neutrality doesn’t mean "anything goes forever in any shape or form". Point to the protocol field that marks a transaction "native." There isn't one, everything BIP110 filters is consensus-valid and fee-paying, so "native" means "transactions I approve of" and your no-censorship claim is circular. Your own source says only 81.1% of blocked transactions classify as spam, so "no native transaction is ever touched" is refuted by your own data. Bitcoin's limits have always been uniform, hitting every transaction identically regardless of content, and you conceded the difference yourself: "optional policy" to consensus. Optional was the neutral part. > No, not necessarily. And even if a split is happening, it will be shortlived, not supported by anyone and it is to be expected that the minority split will be quickly abandoned. SegWit required 95% and Taproot 90% because soft fork safety needs an enforcing majority overwhelming enough to rapidly orphan non-compliant blocks, and signaling isn't enforcement, miners have false-signaled before. At 55% you get persistent reorgs with old nodes flip-flopping between chains, and 2017 teaches the opposite lesson anyway since BIP148 was split-courting brinkmanship bailed out by 90%+ hashrate compliance. Now apply your own numbers: 1% miners, 15% nodes, and a mandatory window where BIP110 nodes reject every non-signaling block, meaning at current support they orphan ~99% of blocks and follow a ~1% hashrate chain with multi-hour block times, rejected by the economic majority. Your "shortlived minority split, supported by no one, quickly abandoned" is an accurate forecast of your own chain, and nobody needs to request exchange listings because a persistent chain with divergent rules is a separate coin by definition. > No. Again an argument where Vortex has it backwards. The actual attack has been ignited by Bitcoin Core. Your threshold defense is a confession. High thresholds don't "reflect less contention," they exist BECAUSE contention is dangerous, the threshold is the safety margin against a persistent split, and contention is exactly when the other 45% of hashrate really will keep mining the old rules. So "higher thresholds stall needed fixes" translates to "the safety mechanism keeps stopping us, so we lowered it," making BIP110 the first activation design in Bitcoin's history built to defeat contention rather than require its absence. And 55% of what, miner signaling? Bare miner majority deciding consensus rules is the exact model the 2017 UASF movement existed to reject, users decide rules and miners order transactions, now inverted to "55% of hashrate suffices over user objection" at 15% nodes and 1% miners by your own count. The Luke and Szabo screenshots criticize a relay default anyone can override today and contain nothing about activation safety, so point 7 stands unanswered, appendix included. > BIP110 doesn’t claim to eliminate all spam forever as spammers can indeed fragment data, use other attack vectors, or wait for expiry of the BIP. Your point 1 called "BIP110 does not stop or slow down spam" a disgusting and blatant lie, and your point 8 opens by agreeing spammers "can indeed fragment data, use other attack vectors, or wait for expiry." That was the claim, you've ended your rebuttal by conceding the sentence you began it calling a lie. "Raises the bar" doesn't survive the math either, ~11% more spammer cost for ~95% more permanent node burden with the compliant variant demonstrably larger than the original. The "already working" tweet loses both ways since inscription decline is a market-wide cycle collapse no 1%-signaling proposal gets credit for, and spammers "making amendments" IS the adaptation thesis, the failure mode cited as proof of success. The 85% of nodes running clients without BIP110 already expressed their position in software, silence isn't mandate, and seven years of free BSV blockspace with zero migration settles "they'll just leave." Notice the pattern: activation is success, failure strengthens the protocol, spam down proves it works, spam adapting proves maintenance works. A theory every outcome confirms isn't engineering, it's faith. Summary: See insults don't help your case, neither does your lack of basic knowledge of how bitcoin works. Here's the scorecard, sources that disagree with each other cited as dual proof. A "restoration" of consensus rules that never existed. Satoshi quoted for a mechanism he never once used while his actual anti-spam tool, fees, argues my side. Breakage conceded as "updates," neutrality conceded as "optional to consensus," split risk conceded as "designed for contention," and the original claim you called a disgusting lie conceded verbatim in your own closing point. Every substantive argument you made either contradicted your sources, contradicted your other arguments, or contradicted itself. I almost didn't even need to debunk this because this entire post is basically a confession of having no idea what's going on.
Show more
Technical objections against BIP-110 that's still looking for refutation: mine: lopp: rearden: kevin: Giacomo: supertestnet: ajtowns:
Show more
@SovereignBTCer @w_s_bitcoin @adam3us @bitstratford @dotkrueger This is why we have the core development process, it's a process, designed to only let the best most functional code through.
LOL I'm not reverting to some fallacy, I've argued at length for the dangers of 110 here: Core was clear about it from the start on their post here: And I've argued why it was good to remove the limit here: with onchain evidence proving it here: Narrative's the same, meanwhile 110 side changes narratives every day: first it was v30 was gonna kill bitcoin, then spam, then it was CSAM which I proved was completely igorant here: Nah there's good reason why 110 lost, because it was ridiculous from the start.
Show more