If you have a strike account you can pay the merchant in Bitcoin using your USD balance with Strike, so its Strike that makes the conversion and you shouldn’t have a taxable event.

Sort of but not really. Best option is to not upgrade to v30. “Core developers have rewritten the v30 configurability setting “datacarriersize=” from signifying what it has meant for years. This user-configurable number used to specify the number of allowable bytes of data that a node’s mempool would accept within one OP_RETURN output. In v30, this same number and setting will now permit nine times more data than that same number would have allowed in v29 and prior versions.” https://protos.com/three-sneaky-changes-in-bitcoin-core-v30-are-confusing-node-operators/

So true!

Not exactly E2EE, but a cryptographic signature confirming who the author was and that the message has not been modified is useful even in large public group chats.

Citrea maxes out op_return at 83 bytes and puts the rest in UTXOs. They might change that because of the v30 deployment. They didn’t use more than 83 bytes because apparently filters DO work as a disincentive. 🤷🏻‍♂️

Immersion mining dramatically reduces noise - and it uses less electricity. This noise problem will be reduced in a few years as miners upgrade hardware.

Wrong - Bitcoin core v30 just changed a default that’s been in place for around a decade with no credible reason for the change beyond “trust me bro - it’s too technical for you to understand”. Critics point out that allowing unlimited data storage in transactions is bad for Bitcoin as money and awesome for shitcoiners. Core replies with a lot of signatures on a statement that still doesn’t explain the change but appeals to their authority. Remind you of anyone?

Duuuuudddeee - learn about this issue. Core v30 opens the floodgates for VC backed startups to store huge amounts of arbitrary data on the Bitcoin blockchain. That’s not what Bitcoin is about. Bitcoin is money - not storage. Knots doesn’t magically fix the spam problem, but they are working on it rather than enabling it. Do the work to read the Core developer mailing list and GitHub threads. Core rejected this change twice in the past two years because it’s bad for Bitcoin and therefore controversial. In v30 they pushed through unlimited data storage despite there still being a lot of disagreement - AND they are still unable to make a coherent argument for why we need to change this default that’s been working fine since 2014.

Hybrid means you still pay a lot of money for maintenance. I’ve had two EVs with close to zero maintenance costs for about 9 years plus a couple of high performance and off-road conventional gas cars. All the gas cars have way more maintenance costs, worse acceleration, and more expensive per mile costs for gas vs. electricity. EVs are the future. EVs are more fun to drive and cheaper (other than whatever the upfront purchase price is). Any EV that can use the Tesla charging network is great for long road-trips. The other charging networks are not very good yet (but will be good in the future). The differentiation is going to be the look/interior finishes/range/prestige of the car. This will take time, but Porsche and Audi are already moving in the EV direction.

I only saw your original note because I enjoy your content, and I assume a lot of other people will read the note and dismiss this controversy as pointless or that the Knots people are naive or crazy. I’m not trying to annoy you. I would like you and the people who follow you to understand this issue deeply enough to realize that the Knots folks are not as crazy as they seem. And even though Knots may not be a silver bullet, we all need to pay attention to this issue and take a stand against the unintended (and unnecessary) consequences from v30 that can damage Bitcoin. One case in point: Core v30 benefits venture capitalists who want an “approved” way for their startups to store large amounts of arbitrary data on the blockchain so they don’t invest in a fragile business model that might get filtered out of existence if both nodes and miners choose not to accept their arbitrary data. For example, Citrea, and their Clementine bridge which needs to store 144 bytes, so intends to span OP_RETURN and UTXOs to achieve that. Jameson Lopp’s arguments on this topic cannot be taken as unbiased because he invested in Citrea. Antoine knows Citrea’s going to spam the network and could have adopted Adam Back’s suggestion of increasing the OP_RETURN datacarriersize default to 160 bytes (for now - revisit in the future if necessary) so Citrea wouldn’t need to spam the unpruneable UTXO set. Instead, Antoine opted for the much higher risk approach of removing the limit to accommodate ALL future use cases of arbitrary data in the blockchain without the risk of failing to make the case to the Core dev community next time. This controversial OP_RETURN change was proposed at least three times since 2023, and Core rejected it the first two times. It was pushed through in v30 despite disagreement within the Core dev mailing list and GitHub discussions. Rhetorical question: If “filters don’t work” then why does the Clementine whitepaper proposal store 80 bytes in OP_RETURN and the rest in UTXOs? Surely they could have put it all in OP_RETURN and broadcast the transaction via Libre relays or directly to Marathon via slipstream? My view is that we should very cautiously increase OP_RETURN and other defaults as use-cases that strengthen the core value proposition of Bitcoin come along. The OP_RETURN changes in v30 that remove the size limit are both reckless and unnecessary. https://citrea.xyz/clementine_whitepaper.pdf?ref=blog.citrea.xyz https://www.prnewswire.com/apac/news-releases/citrea-raises-14m-to-expand-bitcoin-beyond-digital-gold-302289029.html https://citrea.xyz/ https://github.com/bitcoin/bitcoin/pull/28130

Are you intending to include similar spam filtering functionality to what Knots offers?

It’s really as simple as two philosophies: Knots means Bitcoin is money; Core v30 means it’s also storage for large amounts of arbitrary data. I hope more people do the work to understand how bad Core v30 is for Bitcoin instead of dismissing the Knots people as fringe lunatics because they rallied behind Luke (who is definitely a polarizing character). I did the work to read the developer discussions/arguments on the mailing list and in Github, talked to Core devs face-to-face over drinks and then read the actual C++ policy code in Core and Knots (I’m a seasoned C++ developer). The Core dev team rejected this controversial OP_RETURN change at least twice since 2023, and it was pushed through in v30 despite lots of disagreement. Before I read the code, I didn’t realize that Knots is heavily using the Core codebase (so benefits from all the development and testing Core does) but then blocks Runes inscriptions very easily using a single “if … then” line of code that Core refuses to include! Runes code finds its inscriptions in the blockchain by checking if the OP_RETURN data starts with the number 13. Knots uses the same check to reject Runes spam. Core devs will argue that Runes (and other spammers) could change how they hide data. But then Knots devs would look at the Runes code to see the new way it stores data and add another line of code to the next Knots release to block it. This is all that’s required to make life difficult for spammers like Runes (and this scares away venture capital because the spam code keeps getting broken over and over again by node filters, so they need to pay extra to miners to bypass the nodes and face the risk that miners could at any time decide to side with the nodes and put them out of business). So the “cat and mouse” or “whack a mole” game is not really that painful to play, and it protects Bitcoin as money. This is what the Knots dev team has signed up for and the Core team refuses to do for philosophical reasons. Knots includes other spam filters and code changes, and spammers also hide data in UTXOs, but Runes is a simple example to understand the issue. As you can probably guess, I now run Knots!

I think his point was just that the amount of spam competing with financial transactions will increase due to the changes in v30 laying out the red carpet for spammers. Miners don’t care - they mine what’s most profitable for them and have unfortunately degraded into centralized short-term incentivized participants in the ecosystem. If spam ever gets so bad that financial transactions are prohibitively expensive, that’s really bad for Bitcoin. Not everything can live on Layer 2 or sidechains - sometimes we need financial transactions on the base layer. Corporate miners are fine killing the goose that lays the golden eggs as long as they hit the quarterly earnings forecasts and the executives get their bonuses at the end of the year. They’ll transform into AI hosting companies if Bitcoin dies. That’s why node runners need to push back against this Core v30 nonsense and make Bitcoin about money again.

That’s stunning! Is it an AirBnb?

Great idea - I’ve been wondering why this hadn’t already happened to reduce the risk of bugs. The timing now is ideal to increase the number of robust implementations of nodes that are available. We need more choice than Core vs Knots.