Was looking to update the hard-coded and obsolete 6-blocks-to-confirm target in the Knots wallet GUI, but doing the math, it looks like due to the Antpool conglomerate having 48% of Bitcoin network hashrate, even getting to 95% secure requires over 800 blocks. 😭

SCOTLAND - The SNP is now considering banning cats! To protect wildlife (mice and rats fully supportive of the measure) Those already with cats will be forced to use ‘containment’ areas (so they can’t hunt mice and rats presumably) I have nothing 🤷‍♀️🤡

I want to take the opportunity here to clear up some confusion around OP_CAT and the extent to which it enables "ETH-like" protocols on Bitcoin. If you're reading this, and you're wondering "Why Would We Want To Make Bitcoin _Anything At All_ More Like The Garbage Shitshow That is ETH?" and for that reason feel that OP_CAT is unnecessary, l understand that emotion and want to clarify some things. What does OP_CAT do and why do we actually need it? So, everyone who knows anything about Bitcoin knows that the longest dispute/challenge we've had with the protocol is how to make it scale. How do we enable more transactions on Bitcoin, more users, to transact on the chain in a non-custodial fashion? In 2015-2016, we were at a crossroads and basically had to choose between: 1) Increasing the blocksize, making blockchain validation harder to do for the average user at home 2) Attempt to scale using complex "Layer 2" technologies, trying to aggregate as many transactions offchain as possible and settle to the mainnet only when necessary At the time, the downsides of (1) were clear and understood. Many people in Bitcoin felt that it was unwise to go for this option before we had explored (2), myself included. So we explored the Lightning Network, the channel-based, only "real L2" system that was possible to build on Bitcoin at the time (leveraging the OP_CLTV and OP_CSV opcodes that had been recently softforked into the protocol, and later, also SegWit—the latter two softforks activated specifically to enable LN). But Lightning has proven to be lackluster. While it is possible to route around BTC offchain in this manner, in a decentralized way, many, if not most LN-engineers are deeply frustrated with the complexity of the protocol. While marginal improvements have been made, we're still stuck with a channel-based, liquidity-management-based scaling system that drives most people to use custodial solutions, undermining the core premise of Bitcoin (self-sovereingty, privacy, censorship resistance). So, unless we want to surrender and actually make the blocks larger, we have to make Layer 2 protocols easier to use. The main roadblock to make Layer 2 protocols that are channel-free and easy to use is the lack of ability to in code specify how a Bitcoin transaction output (UTXO) can be spent. This technical detail is what's known as "covenants". There are many proposals for how to enable covenants and a lot of politicking involved in how to choose the right one. We've been observing the covenants debate deadlock for years. One of the leading proposals, called OP_CTV, has failed to win sufficient community consensus, and has often been bikeshedded by leaders in the industry with arguments such as "Why don't we just re-enable OP_CAT which exists today on sidechains like Liquid and altcoins like Bitcoin Cash?" If the primary holdup to activate covenants are questions like "Why don't we just activate OP_CAT instead?" then I think it's worthwhile to force the conversation and say, "Yeah, how about it? Why don't we just activate OP_CAT?" In May last year in Austin, at the most high-density Bitcoin developer conference of the year, @btcplusplus, developer consensus that are in some flavor in support of adding the functionality of OP_CAT was gauged and the overwhelming sentiment was that OP_CAT is actually something that we want in Bitcoin. Again, the introduction of OP_CAT is a way to introduce covenants into Bitcoin, with the core purpose being to break Bitcoin free from the lack of functionality that prevents it from being able to host good Layer 2 protocols (that don't require channels, trust, or inbound liquidity). Yes, it is true that these Layer 2 protocols will also be able to run Ethereum-like computation ontop, instead of just being scaling mechanisms, but OP_CAT overall is not an "Ethereumification" of Bitcoin. Bitcoin Core won't be any costlier to run at your home computer with OP_CAT, Bitcoin Script won't be running complex Turing complete computation, Bitcoin won't be managing more data onchain than the current 4MB block limit allows, it won't have rich statefulness, it will still be using the same old rudimentary UTXO-model at the baselayer. The only difference being that that rudimentary UTXO-model can now concatenate elements and verify if a hash belongs in a particular Merkle tree, and carry state from one UTXO to another, enabling every UTXO to operate as a tiny "state machine" in and of itself. This allows more powerful, user-friendly Layer 2 protocols, such that users can actually use them non-custodially and not keep their funds in custodial wallets, as we see with most leading Lightning efforts today, defeating the purpose of using Layer 2 protocols in the first place. So, would OP_CAT allow more "ETH-like" protocols to run ontop Bitcoin? Yes! It allows for channel-free, permissionless, user-friendly L2s to be built. Does OP_CAT make the Bitcoin Layer 1 "ETH-like"? Not by a longshot.