I can't speak for the "spam companies and projects", but as far as we're concerned:

I'm not going to emphatically say "no" because who knows, maybe in the future we'll have some application where it makes sense but we currently do not. We have released and sold two inscription collections (that both put data in witness data). In both of those cases, it's not clear to me that having the data in OP_RETURNs would have been better. The main reason we put the data in witness data was for compatibility with the ordinals protocol. Our collectors want to be able to manage, store, and trade our collection in wallets they're already using -- and there are several ordinals-specific wallets out there, and any wallet with coin control could technically be used. You could add opreturns to ordinals, but it would be weird. imo, having inscription data in the input instead of the output makes the protocol cleaner and easier to implement.

So for our collections, compatibility is a bigger concern than something like the witness discount. High-value inscriptions are actually reasonably price-insensitive when we're talking about a 4x cost premium. We did a LOT of work on Quantum Cats to bring the cost down, but that was by a factor of about 100, not 4.

Outside of digital collectables, we've done a lot of work with OP_RETURNs holding data commitments for multi-transaction protocols using OP_CAT or other covenants. In those cases, usually we're putting one or two merkle roots and maybe a little metadata tag in an opreturn. So we actually haven't felt any real pain with the 80-byte limit. We actually run into consensus limits more often than we run into the OP_RETURN limit.

In general, if we did want to stick a bunch of data into an opreturn it would probably be something where:

Nothing currently fits that bill, so I don't think so, but you never know. Maybe some of the people mad about this have a fun idea they can share.

nope. we're a Bitcoin company.

Knots is a fork of more. So it uses the same fee estimation as core.

What you ideally want to make a good fee estimates is to see whats in the template at as many mining pools as you can. You can’t, but the network is well-connected and the overwhelming majority of hashrate generally sorts by fee rate (plus some tx acceleration) so having a well-connected node and sorting by fee rate does a really good job.

Other “noderunner preferences” doesnt change things unless they are getting transactions to miners that you don’t see.

I think you are confused about fee estimation.

The core fee estimator works one way (looking at recently confirmed blocks). The mempool-space estimator works differently (looks at what is in its mempool). There are other fee estimation algorithms out there too.

The core algorithm tends to not work well when there are rapid changes in the mempool, because it looks at what has already been confirmed. For steady activity, thats fine but hasnt worked as well as the mempool-space approach for the last two years.

A good fee estimator will help users pick the right fee to get confirmed in the time they prefer. In other words, if you pay for next block, you usually get it and are not grossly overpaying. The core fee estimator isnt better just because its in core.

Also, fee estimators aren’t consensus or policy. They’re a tool.

This:

Doesnt make sense

mempool-space’s fee estimation is waaaay better than whats in core (which is what youre describing when you talk about it being accurate).

mempool-space is awesome

just use mTLS. its literally for this

yeah maybe. But then again maybe you negotiated your bitcoin-denominated pay at the top of a cycle and then for the next 2 years are making 70% less than you thought.

The same thing happens in industries (tech, for example) where a large chunk of total compensation is equity. It's nice for the upside, but you still want base pay to be in the same currency you use to pay rent and buy groceries.

you guys did a LOT to push the state of the art on noncustodial financial services. Thanks for all the hard work! I think I'll be missing itchysats forever.

as tasteful as always

What has been most surprising or unexpected to you while building BitKit? Any particularly interesting discoveries in customer behavior, product strategy, tech, etc?

is that right? 24.5 m^2 is ~265 sqft.

This is great. "Who Wrote the Code" is still my favorite. But this is great too

finally a good use of LLMs

Hang in there dude.

Why are covenants for noobs?

I want vaults. Those aren’t for noobs.

Exciting to see progress on package relay and cluster mempool