Despite all the liquidity flowing into AI stonks are not feeling well.

ETFs are selling Bitcoin low and will be buying it high. I think that is good opportunity for Bitcoin Plebs.

Running BIP110 View quoted note →

Magnifique View quoted note →

By @SteveSimple A "Key Takeaway" of how Taproot was advertised to the community was: "Tapscript removes the 10,000-byte script size limit and 201-opcode cap from legacy Script, enabling more complex contracts while using a per-script signature operations budget for DoS protection" spark.money/glossary/bip-342 Removing these limits was based on Taproot's clever avoidance of the primary denial of service (DoS) attack vector in pre-Taproot scripts. Specifically, Taproot disabled Segwit's inefficient multisig method, and redesigned its script resource accounting, so those DoS concerns were gone. With the DoS no longer in play, the justifications for raising the limit were: 1) it enables more complex contracts (widely stated), or 2) there's no reason not to (why not?) That rationale was over four years ago. Taproot was activated in November 2021. To date there have been 424,471 Taproot scripts larger than 10KB that have been revealed through spending. The analysis script (which you can verify from your node using the GitHub link) evaluates all scripts of this type to date. Every revealed Taproot script-path spend over 10KB is evaluated, none excluded. The results are clear. Of the 424,471 scripts to date: 1) 99.98% were data storage. 2) 99.89% placed their payload in a branch that can never execute (OP_FALSE OP_IF provably dead code). 3) 0.091% were bulk data-push scripts that did not use the dead-code method (no dead code but >50% of the bytes in the script were pushes of data larger than 80 bytes). 4) 0.018% can be classified as complex executable contracts (not data storage). Almost all of these are BitVM-like scripts. 5) Exactly one (1) of the complex scripts that were not data storage was a multisig using hundreds of OP_CHECKSIGADD. In hindsight, we now have overwhelming evidence of how the raised 10KB Taproot script limit was used in practice. It was used for data storage. There was essentially no on-chain verifiable demand for enabling complex spending scripts that were not data storage. And it isn't free. Every byte sits in the witness of a spend. It's downloaded, validated, and stored forever by every archival node, at the discounted witness rate that makes dumping it cheaper than real transactions. Removing the cap enabled essentially no complex contracts (0.018%). It externalized a permanent storage-and-bandwidth cost onto everyone running Bitcoin. And for what. For data-storage scripts that are 99.89% unexecutable dead-code branches.

GitHub

GitHub - Unbesteveable/taproot-10kb: How the raised 10KB Taproot script-size limit is used in practice: dead-code data vs bulk data vs executable contracts, from a Bitcoin Core node.

How the raised 10KB Taproot script-size limit is used in practice: dead-code data vs bulk data vs executable contracts, from a Bitcoin Core node. -...

#BIP110 & #BitcoinKnots because Bitcoin is Freedom Money

#BIP110 & Bitcoin #Knots

I think the cantillonaires and banksters are really scared of Bitcoin being Freedom Money and working as intended.

Core are completely corrupted and compromised. Core V30+ is a malware and an attack on Bitcoin Freedom Money.

This will be pure diamond 🤘

💯 Don't forget that Peter Thiel from Palantir, Jameson SLopp, Erik Voorhees, Orkun Mahir Kılıç and other bad actors and scammers are investors in Citrea. Citrea's centralized created out of thin air slavery shitcoin on top of Bitcoin. View quoted note →

#BIP110 "A deep-dive game theory analysis and code audit of Bitcoin's "Reduced Data Temporary Softfork", examining what the mechanism design reveals and what the code actually does."

melvin.me

BIP-110: Game Theory & Code Audit

A deep-dive game theory analysis and code audit of Bitcoin

El Salvador keeps winning with Bukele

Bullish BIP-110 View quoted note →

History lessons ... they lost the war with inflation because that war is impossible to win in a debt based printer goes brrr economy Weapons against inflation (1978) — with Alan Greenspan | ARCHIVES

20 million out of 21 million Bitcoin is already mined. The last 1 million Bitcoin will be mined during the next 114 years. Bitcoin is the hardest Freedom Money on planet Earth. Bitcoin is the true market signal. Tick tock, next block.

TLDR: Andy Back is full of shit. Core are corrupted and compromised. A very nice long read! By @Beautyon_ The claim being made here is that Bitcoin Core's development uses an "IETF-like consensus process," presented specifically as a reason the OP_RETURN relaxation in Core v30 should not be second-guessed by plebs. The claim is very subtle, and partially uses the appeal to authority as thrust, but it's fundamentally wrong in the end. IETF codifies its process in published "Best Current Practices"(BCP 9, BCP 25 and related RFCs). The motto is "rough consensus and running code." Critically however, rough consensus is not unanimity and explicitly does not grant objectors a veto. A minority that has been heard and answered can be overruled however, so the mere existence of objections never, by itself, defeats consensus. Beyond the pithy slogan, the legitimacy comes from procedural machinery not slogans: working groups chartered with a defined scope; a neutral chair who is responsible for judging whether rough consensus exists and documenting why; formal Working-Group Last Call and IETF-wide Last Call periods of fixed duration; IESG review where Area Directors can lodge a blocking "DISCUSS" that must be resolved; and a multi-level appeals process (chair → Area Director → IESG → IAB) on both technical and procedural grounds. Take note that the people advocating a change are structurally separated from the people who declare that consensus has been reached, and any such declaration is contestable. OP_RETURN's size cap (the ~80-byte default and the one-output-per-transaction default) was never a consensus rule. It was relay/standardness policy of what a default-configured node will accept into its mempool and forward, not what is valid in a block. Miners could already include larger data, and users could already change the setting in the bitcoin.conf file. The v30 change removed those default limits (relaxing -datacarriersize / -datacarrier and the multiple-output restriction), making large and multiple OP_RETURN outputs standard by default. This is the controversial move, in addition to the planned eventual deprecating of the lever itself, cutting off user choice entirely. The mechanism to do this was am ordinary GitHub pull request reviewed by via ACK/NACK, with maintainers alone deciding when "sufficient" review existed to merge. This was a small group of insiders who were provably hostile to outsiders and who would brook no interference in their unilateral decisions. The myopic technical argument for it was that the limit was trivially bypassed via out-of-band submission to miners, and that it pushed spammers toward fake spendable outputs that permanently bloat the UTXO set, whereas OP_RETURN is provably prunable. This of course ignores the demonstrated side effect (bCash, that increase this parameter and got flooded with porn) that the unpruned database would be absolutely be increased in size without a proper reason, with non financial and illegal data. That is the argument against: it normalizes non-financial spam, exposes node runners to legal risk, and changes Bitcoin's character, and was merged over essentially correct, large-scale objection, hence there was no consensus. The ethos attributed to Bitcoin Core genuinely rhymes with the IETF rough consensus rather than voting, emphasis on working/tested code (however, confirming code in a test script is not the same as running it in the human context of a live financial network with financial incentives to spam), open participation (in Core's case this is obviously not true, as they delete opposition), public archived discussion (also not true, as they change the history by censoring and deleting input from opposing voices), and Back's implicit corollary is correct on its own terms: in a real and actual IETF process (which is not what Core has), NACKs and a stream of GitHub thumbs-down would not automatically block a change. The naive critic's syllogism ("there were objections, therefore no consensus, therefore illegitimate") misunderstands the IETF as much as it does Core. To that extent, Back has a defensible point and the thing he's mocking, treating disagreement as a veto, is not how the IETF works either. Where the analogy breaks, and breaks precisely on the dimension he invokes, is the IETF's legitimacy is not in the slogan but in the machinery around the slogan, and that machinery is almost entirely absent in Core. In Core there is no neutral chair whose job is to adjudicate and document whether rough consensus exists; the maintainers who merge are the same population advocating the merit, so advocate and arbiter are fused; an obvious and blatant conflict of interest. There is no chartered scope, no formal Last Call window, no IESG-style blocking review by a separate body, and most importantly, no appeals process, all of which would have avoided the current situation, but which were explicitly rejected by Core. Core is essentially therefore, a dictatorship in IETF clothing. In the IETF the assertion that, "this was declared consensus improperly" is itself a reviewable, appealable claim. In Core, that same complaint has no procedural avenue; the only recourse is exit; running Bitcoin Knots or a custom config. That exit option is also weaker than the IETF equivalent, because of a category difference Back's analogy elides. IETF outputs are voluntary specifications; an implementer who dislikes an RFC simply doesn't implement it, with no effect on anyone else. A Bitcoin Core relay-policy default has emergent, very serious, even lethal network-wide consequences; what the bulk of the default-configured network relays and what therefore reaches miners. This is a known emergent behaviour once again, thanks to the experiments run by bCash, where the predicted outcomes of increasing OP_RETURN have already been seen. "Run different software" is a real safety valve, but it is not the clean, consequence-free opt-out that ignoring an RFC is. On the consensus controversy specifically, this is where the claim is at its weakest and most threadbare. The real defect is who overruled the community and by what reviewable procedure; in fact there was no procedure in place. In the IETF, overruling a minority requires a neutral party to declare rough consensus, give reasons, and expose that declaration to appeal. The OP_RETURN merge had none of those features. So invoking "IETF-like consensus process" to defend that particular decision selects the one comparison the decision least satisfies: the IETF's distinctive contribution is exactly the neutral consensus-call-plus-appeals apparatus that was missing here. The fact of the matter is that the parts of the IETF that are genuinely consensus-process (neutral arbitration, last call, appeals) are the parts Core deliberately lacks, and the parts Core shares (rough-consensus ethos, running code, open lists) are the parts that don't, by themselves, resolve a contested "was there consensus?" question. Back therefore can't invoke IETF in the way that he does, attempting to transfer the credibility of the IETF to Core by Meme Magic, because Core does not share the IETF's essential attributes and processes. Back is partially correct as a very rough and ready, Social Media influence attempt ethos analogy but it is fundamentally incorrect, and materially overstated as a description of governance structure, and the OP_RETURN case is close to the worst example he could have chosen to anchor the claim, because the controversy turns on the absence of precisely the IETF features that confer procedural legitimacy. The OP_RETURN inclusion process was illegitimate on its face therefore, and this cannot be argued against cleanly by invoking the IETF. Core's process is better described as maintainer rough-consensus with exit-by-forking than as IETF-like. It shares the IETF's slogan, but that is simple Virtue Signalling; it does not share the IETF's separation of powers, neutral consensus determination, or appeals. Which are the important parts that make the IETF actually legitimate, and not just appearing to be legitimate. The Core Conspiracy, which it can be rightly called because a small number of people and corporations literally conspired to increase OP_RETURN, cannot be transformed into something legitimate by simply comparing it to something that is actually legitimate.