author

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 10 of 6,464 analyzed posts/comments in the seven days ending that day (11 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-17 16:34 UTCComment

   It's hard to say what 110 is really about. Sometimes it's proponents say it's about stopping spam, but when it's pointed out that it very much doesn't (ordinals/inscriptions already has an update to avoid it, e.g.) they pivot to saying it's not about spam. The substance of it is that it *radically* restricts transactions-- it removes OP_IF, it removes the facility for safe upgrades (OP_SUCCESS), it even cuts out the very first script type used in Bitcoin, pay to pubkey. The reason it does this is that it's trying to close down ways to put extra data in transactions. But inherently you can't because transactions have to contain things like keys and signatures and hashes that can just be made arbitrary data because they're random numbers. An effect of shutting off these things is that it'll cause funds loss-- if you pay to an address that use those feature (e.g. created before 110) those funds will be gone. Or if you've got a timelock where the presigned spend uses them, again funds gone. Every past soffork since Satoshi has put a lot of effort into not accidentally confiscating anyone's funds, but in this case the authors of it just don't care. And when people have complained they've just ignored it or denied it. The other effect is to hamper bitcoin's flexibility-- want secure your families inheritance with a 3 of 6 multisig where each key has a backup? It blocks that because it removes OP_IF and limits script tree depth to 7 (instead of 128). From logs people have sent me from the author's discord I feel comfortable saying that the real purpose of the proposal is to "fire core"-- similarly to Bcash. In order to do so the proposal had to be intentionally bad and overbroad. Had they just proposed capping op_return to 510 bytes, there are good odds that if there was popular support for that that the bitcoin development community would sign on too, and fail to achieve the desired effect. But in any case, it's just a crappy proposal. And it's crappyness is seems to be generally reflected by the fact that it's not supported by people with skin in the game. I think it's pretty telling that none of the 110 supporters will accept offers to do a zero-trust non-110-coin for 110-coin coinswap.

4. 2026-07-17 16:03 UTCComment

   > OP_IF is the cause of the exponential blowup when used by inscriptions. No. Quite the opposite, the use of OP_IF in inscriptions is because it saves them a couple bytes bytes per transaction. It absolutely doesn't cause any blowup or increase what they can store (beyond a couple bytes). > each condition can be expressed as separate leaf. No, it cannot because there are an exponential number of leafs from multiple conditions and even if you didn't mind your computer needing to hash terabytes of data to build your scriptpubkey, they cap the tree depth to 127, making things like a 3 of 6 multisig with backup keys not possible to represent. So it is not just making it less efficient, 110 severely limit whats it can do. Unfortunately the authors of 110 lack the technical competence to understand that IF is an intentional and important feature. > BIP110 removes it only from tapscript, not from sw multisig. Right so now you have your more complicated multisig always forced onto the chain when you could often sign with the root instead. Blowing up your privacy and bloating the chain. > this is only ppl who made a taproot timelock after the default for the size was changed "default for the size"??? sounds like you're thinking of op_return. Absolutely not. 110 bans scripts that are currently in use. No op_return involved. This means that if someone uses an address generated before (or reuses) or if you have timelocks that use these scripts the funds are then gone. And no, timelocks secure at least millions of dollars of bitcoin and are in production and have been for a very long time. It's not some "for testing" thing. > 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. Yes, it's not expensive at all. I believe the change inscriptions did to adapt to 110 increases the weigt of their transactions by less than half of one percent. Most NFT things don't have any weight increase at all as a result. > cool we are considering bloat of dozens of bytes of rare transactions while ever since Taproot activation the avg blocksize rose by 0.5MB average blocksize is 1.6 MB and has been that for a long time. Indeed it was elevated during the NFT mania, but OTOH those blocks are much faster to validate and for most people speed up synchronization.

5. 2026-07-15 00:55 UTCComment

   Read the discussion here, the gist of it: It won't. 110 doesn't block spam or even materially impair it-- even the authors have been forced to admit this. Instead they say it's about sending "a message". But even if it did block stuff it comes at a very high cost, doing damage to purely financial transactions. If they want to send a message the place to do it isn't Bitcoin's consensus rules, they can send an email. I guess you could say 110 spams up the consensus rules. :)