The utxoset size is *permanent* it can’t be pruned like other block data unless you consolidate the spend into a smaller set of utxos

basically think of them as a coin purse where if you put two coins in, the only way to shrink the bag is to spend to coins with no change.

JPEGs in witness data means that they will likely be unspendable, meaning that there is a permanent storage increase requirement on all nodes. But they are no provably unspendable so you can’t discard them from the coin purse. This is really bad.

OP_RETURNs are *provably* unspendable, meaning they can be ignored from the utxoset perspective (never goes in the coin purse)

By trying to stop both witness jpegs and large OP_RETURN pushes, it will push people to do even worse things like large multisigs that stores data in the signatures. This is how the whitepaper is permanently stored in the utxoset. This is even worse for utxo bloat.

At this point the censor proponents would say well thats not economically viable… but none of these methods really is. Some are cheaper than others, sure, but overall it’s still the most expensive data storage out there. People have to burn the hardest money on the planet if they want to play stupid games.

The point is people are going to store data anyway, the *least bad* is OP_RETURN, because it minimizes the *permanent* storage burden on pruned nodes.

You know at some point in the future the left is going to come out in favor of robot rights. Like you just know it lol

Drain the wealth from the unguarded storeholds of value which are already overrun with parasites. Call parasites out when you see them. Say no much more often. Have a spine. Don’t back down. Create new systems to replace the old ones. Fight to win. Basically all the bitcoin stuff we talk about

was hooked by balatro, now slightly addicted to slay the spire. trying monster train next. deckbuilder roguelites 🤌

losing is fun!

What I hate is exactly what you mentioned. There's a whole ecosystem of bad frameworks and your job is to find the least bad one. For me it's react/typescript/webpack etc. it took me so long to hack it together. I think I may have actually cried at one point.

The hardest Optech newsletters to write are those where we summarize unresolved disagreements, e.g. for or against CTV+CSFS. When everyone ends up in agreement, at least mostly, we can skip describing any arguments and jump to the conclusion.

But when there's no resolution, we have to get into the details, try not to miss anything important, and be careful not to summarize in a way that misstates someone's key argument or attributes to them an opinion that they don't actually hold. On top off that, there are arguments that seem weak to me but which probably warrant describing in case I'm missing something. All that extra work is important but it's not my favorite.

Also, it makes for long and hard to read newsletters, so sorry about that for next week.

Doesn't matter who wins the election, Canada is done.

We’ve made it to Return of the Jedi in our weekend marathon of the original Star Wars trilogy. The storm troopers always crack me up 😂

The node is on the phone!

With the caveat that you need a router that can work with it. Might block trackers, but it never blocked ads for me, and blocking domains increases your chance of just breaking your internet browsing.

I see some GitHub issue commenters saying they operate leveldb DBs with multiple Tabs and 100s of billions of entries with no issues.

I haven't done the math yet but I think it would take decades of constant utxo spam at a 4 MB per 10 minute rate to get there.

Oh for sure script validation is a more "real and present danger". I'm discussing more theoretically; the "state" is the utxo set, and theoretically you need all of it to do validation. Blocks, you don't. I think cardinality is relevant, though I'm not sure in detail, based on the size of a utxo serialization being roughly constant.

Lookups in a set aren't free, so a limit must exist somewhere, right?

Oh for sure script validation is a more "real and present danger". I'm discussing more theoretically; the "state" is the utxo set, and theoretically you need all of it to do validation. Blocks, you don't. I think cardinality is relevant, though I'm not sure in detail, based on the size of a utxo serialization being roughly constant.

Lookups in a set aren't free, so a limit must exist somewhere, right?

It doesnt have the concept of the utxo set or the mempool in memory, just a database of transactions where confirmation status is only one field.

It's also multi CPU core, but I'm not sure how this relates to your question...

At what number of utxos does Bitcoin (let's say the Core implementation) fall over and crash?

At what number does it become impossible to run with a consumer grade laptop (let's say 16GB ram and plenty of disk for argument's sake)?

#asknostr #bitcoin

(For reference we hit 180M+ utxos in the last couple of years due to runes and whatnot; utxos are not very expensive to make)

So the ByBit attack was able to happen because:

Gnosis Safe front end is a web app whose JavaScript gets served from an Amazon S3 bucket.

A Gnosis Safe developer had production AWS keys saved on their machine.

The Dev's machine was compromised and the AWS key used to deploy a malicious front end that only targeted ByBit's wallet.

JavaScript web apps have no cryptographic integrity checks to ensure the code being delivered was actually written by the expected author.

Signing complex EVM transactions can't be done securely on airgapped hardware because the hardware simply doesn't have all of the contextual information needed to know the outcome of executing the transaction.

Getting on a plane tomorrow. Any movie suggestions?