taproot

Attention over time

7-day rolling share of analyzed posts/comments mentioning this entity · 90 daily points ending 2026-07-18

Final complete day: 2026-07-18. Attention was 0.2% — this entity appeared in 11 of 6,464 analyzed posts/comments in the seven days ending that day (12 mentions).

Each point is a seven-day rolling window of complete UTC days; a point is comparable only when at least 100 analyzed posts or comments fall inside it. A day with no analyzed records counts as zero; missing coverage is marked and never shown as zero. The series ends at the latest complete analyzed day — it never extends into the current incomplete day. How attention is measured.

Recent mentions

1. 2026-07-18 19:21 UTCComment

   110 is a solidly bad proposal, which at best attempts to solve yesterdays problems unsuccessfully, and has been pushed forward with a bad process, and were it successful sets a terrible precedent. It radically handcaps bitcoin's programmability and upgradability (e.g. removing OP_IF and OP_SUCCESS, and capping taproot to a depth of 7), invalidating existing scripts people use today which will cause funds loss due to (re)using addresses that become undependable under it and invalidating presigned transactions. If I were trying to come up with a proposal that would handcap bitcoin against competing altcoins over the long run I don't know if I could come up with something better than this. Embedded data in bitcoin is usually a total non-issue, -- the last spam floods were about two years ago, and today they're just a memory. The controls that exist in Bitcoin work and confine fad data floods to brief inconvenience. The ability for people to run nodes is protected by the blockweight limits, data generally makes nodes *cheaper* to operate if has any impact at all. The NFT traffic that is most common today isn't even inhibited by 110. And the inhibited traffic like inscriptions has already got updates to avoid 110. Unfortunately the non "spam" traffic of actual transactions that 110 blocks can't simply change to avoid it-- that's an advantage that embedded data enjoys because it doesn't need any particular processing by bitcoin. The authors and proponents of 110 have continually provided conflicting statements about its benefits justifying it on the basis of spam in one breath then literally calling people morons for thinking its about spam when it's pointed out that it doesn't stop or even inhibit spam. Rather than addressing serious problems about its safety and negative impacts, they've resorted to vile personal attacks against anyone opposed to 110-- wrongfully and baseless calling them spammers or even p e d o s (spaced text because of dumb automod) in a desperate attempt to suppress criticism. 110 was designed to activate with only 55% hashpower support, or once a deadline is reached (which we're a few weeks a away from) 0% hashpower-- essentially guaranteeing a chain split results. 110's primary creators clearly value getting their way over protecting the value of Bitcoin. The only node software supporting it is created by a single quarrelsome and somewhat odd developer and it has clearly not undergone rigorous testing. There is no 110 testnet. There have been repeated late discovered problems, including another one just today: which shows that fairly basic testing has not been performed, as the same case of nodes upgrading after activation was handled fine in the past (e.g. segwit). The whole premise of 110 is that an intolerant minority of Bitcoin participants get a veto over transactions they don't like. I don't like NFT "spam" traffic either, nor do I think any of the regular developers of Bitcoin Core do. But Bitcoin's entire value proposition is money you can transact without the approval of third parties. A cost for this is that some people are always going to use it in ways we don't like. And 110 actually blocks people's use of money-- be it older script types like pay-to-pubkey (like Satoshi used!), or when you secure your coins with sufficiently fancy multisig policies. Moreover the *process* used by 110 and their proposed roadmap going forward with annual forks to adjust blocking rules, could be used to block literally anything or more precisely any person. Bad restrictions on freedom almost always start with moral cries that almost everyone could agree with ("Think of the children!")-- and then that power is deployed more widely. Bitcoin was intended from day one to take other people's power away from controlling your money, not the power of a state, not the power of a majority, and certainly not the power of an intolerant minority. Satoshi described bitcoin is a system free from third party control "no matter how good the excuse, no matter what". I think this essay casts a light on why there is a vocal minority that is extremely in favor of and confident in this absolute lemon of a proposal.

2. 2026-07-18 16:51 UTCComment

   110 is a solidly bad proposal, which at best attempts to solve yesterdays problems unsuccessfully, and has been pushed forward with a bad process, and were it successful sets a terrible precedent. It radically handcaps bitcoin's programmability and upgradability (e.g. removing OP_IF and OP_SUCCESS, and capping taproot to a depth of 7), invalidating existing scripts people use today which will cause funds loss due to (re)using addresses that become undependable under it and invalidating presigned transactions. If I were trying to come up with a proposal that would handcap bitcoin against competing altcoins over the long run I don't know if I could come up with something better than this. Embedded data in bitcoin is usually a total non-issue, -- the last spam floods were about two years ago, and today they're just a memory. The controls that exist in Bitcoin work and confine fad data floods to brief inconvenience. The ability for people to run nodes is protected by the blockweight limits, data generally makes nodes *cheaper* to operate if has any impact at all. The NFT traffic that is most common today isn't even inhibited by 110. And the inhibited traffic like inscriptions has already got updates to avoid 110. Unfortunately the non "spam" traffic of actual transactions that 110 blocks can't simply change to avoid it-- that's an advantage that embedded data enjoys because it doesn't need any particular processing by bitcoin. The authors and proponents of 110 have continually provided conflicting statements about its benefits justifying it on the basis of spam in one breath then literally calling people morons for thinking its about spam when it's pointed out that it doesn't stop or even inhibit spam. Rather than addressing serious problems about its safety and negative impacts, they've resorted to vile personal attacks against anyone opposed to 110-- wrongfully and baseless calling them spammers or even p e d o s (spaced text because of dumb automod) in a desperate attempt to suppress criticism. 110 was designed to activate with only 55% hashpower support, or once a deadline is reached (which we're a few weeks a away from) 0% hashpower-- essentially guaranteeing a chain split results. 110's primary creators clearly value getting their way over protecting the value of Bitcoin. The only node software supporting it is created by a single quarrelsome and somewhat odd developer and it has clearly not undergone rigorous testing. There is no 110 testnet. There have been repeated late discovered problems, including another one just today: which shows that fairly basic testing has not been performed, as the same case of nodes upgrading after activation was handled fine in the past (e.g. segwit). The whole premise of 110 is that an intolerant minority of Bitcoin participants get a veto over transactions they don't like. I don't like NFT "spam" traffic either, nor do I think any of the regular developers of Bitcoin Core do. But Bitcoin's entire value proposition is money you can transact without the approval of third parties. A cost for this is that some people are always going to use it in ways we don't like. And 110 actually blocks people's use of money-- be it older script types like pay-to-pubkey (like Satoshi used!), or when you secure your coins with sufficiently fancy multisig policies. Moreover the *process* used by 110 and their proposed roadmap going forward with annual forks to adjust blocking rules, could be used to block literally anything or more precisely any person. Bad restrictions on freedom almost always start with moral cries that almost everyone could agree with ("Think of the children!")-- and then that power is deployed more widely. Bitcoin was intended from day one to take other people's power away from controlling your money, not the power of a state, not the power of a majority, and certainly not the power of an intolerant minority. Satoshi described bitcoin is a system free from third party control "no matter how good the excuse, no matter what". I think this essay casts a light on why there is a vocal minority that is extremely in favor of and confident in this absolute lemon of a proposal.

3. 2026-07-18 10:43 UTCComment

   this "Explanation" is a bunch of misleading bs. it assumes that Bitcoin by design was supposed to give everybody loads of space for arbitrary data, whereas the real story is that the very possibility of abusing taproot in this way (inscriptions) was made possible by Core ignoring the proposed fixes for this in the very early stage. The ORIGINAL Bitcoin never gave you chance to upload anything more than ~80 Bytes of storage, so STOP appealing to Satoshi and all this "open block space market", you liars. THEY made this problem (allowed inscriptions) and now they offered solution (open up 100KB) that now undermines the entire network credibility and causes irreversible long term reputational damage!

4. 2026-07-17 09:53 UTCComment

   >OP\_IF is an intentional and important feature. Without it any conditional logic in scripts has an exponential blowup. OP\_IF is the cause of the exponential blowup when used by inscriptions. each condition can be expressed as separate leaf. even if it is not more efficient in some edge cases. BIP110 removes it only from tapscript, not from sw multisig. >But even if it wasn't necessary it's used in people's scripts today so to take it away results in funds loss when an address that uses it gets (re)used, including as a result of timelocks. this is only ppl who made a taproot timelock after the default for the size was changed + used an implementation that exceeds it in the first place AND only if said timelock unlocks within the year. calling it a "funds lost" is fearmongering bs that concerns like 2 devs that use timelocks in the first place for testing. >The claim that removing it is useful for discouraging spam was the thing that was debunked, by stuff like inscriptions creating the trivial change to simply not use it. this is a logical fallacy - just because it is possible to put spam into a bip110 block doesn't mean it will not prevent it meaningfully. How trivial the change is doesn't matter, how expensive it is to spam does. >IF is also space efficient if a condition is smaller than 66 bytes then making it an extra leaf makes the transaction larger, requiring higher fees and creating blockchain bloat. cool we are considering bloat of dozens of bytes of rare transactions while ever since Taproot activation the avg blocksize rose by 0.5MB with a sustained period of 2MB+ blocks during hype.

5. 2026-07-16 15:49 UTCComment

   Thank you for responding! I appreciate the time it is taking for you to answer questions in this controversy. I know there is a lot of information out there for the plebs to absorb, and a lot of us get deep into the weeds (as this is required) and get stuck or lost. I don't think there's animosity on either side, but because there's so much technical information required to even start to understand the issues, we have to choose our experts, and that ends up being who we feel is most trustworthy. Just a few more questions, if I may: 1) Has it always been possible, and will it forever be possible, to embed illegal images into the Bitcoin timechain? Is it not possible at all to stop this? 2) Bitcoin is supposed to be a decentralized ledger for tracking money accounts. It's not supposed to be used for file storage. Is that accurate? If so, what can be done to return it to that basic functionality, if anything? 3) There is a chart showing a significant increase in unspendable UTXOs caused by inscriptions (or Taproot or whatever). That seems to clearly be a bad thing. What is the actual problem, and can it be fixed?