Avatar
rfkill
c5273075de02a2beedad450ff60f0d47c67f28a2299fb804611d3ee5219df5f4
bitcoiner, privacy enthusiast, nix user. Not setting zaps until there is non-DNS based way to do it.

Back in the day it was reasonable to think there would be SOME usecase for ethereum that wasn't:

* creating a shitcoin

* better off done with a database

* better off just using bitcoin

Turns out there wasn't.

It feels like the most important step of learning something in CS is to buy the O'Reilly book and then never open it but just use online resources for everything.

The difference in size between the Go O'Reily book and the Rust O'Reily book is telling.

Replying to Avatar Cyph3rp9nk

The trees obscure the forest

A summary:

Ways to insert data:

1) OP_RETURN outputs (“nulldata”)

You put the bytes in a non-spendable output (scriptPubKey starting with OP_RETURN).

Advantages: does not widen the UTXO set; easy to detect/filter; highly visible in explorers.

2) In the witness (SegWit/Taproot) — e.g., inscriptions

The content is serialized within an unexecuted conditional (“envelope” OP_FALSE OP_IF ... OP_ENDIF).

Advantages: witness bytes “weigh 1 WU/byte” (≈¼ of a vbyte), so it is much cheaper per byte than non-witness/OP_RETURN.

Disadvantages: pruned nodes may discard old witnesses (you don't rebuild them locally).

3) Data in spendable scriptPubKey (“fake” multisig, etc.)

Like the famous case in the whitepaper (2013): bytes distributed across 947 outputs within the scriptPubKey.

Problem: if those outputs remain unspent, the bytes live in the UTXO set ⇒ unspendable until they are spent. This is the least recommended approach today.

4) Coinbase (miner's transaction input script)

Miners can put text/tags in the coinbase scriptSig (in addition to the mandatory height per BIP34).

Useful for messages or pool identifiers; not a general approach for large files.

5) Commitments via Taproot key tweak

You don't store the blob, you cryptographically commit to it (e.g., to its hash) by “putting” it in the Taproot key tweak.

Advantages: cheap and clean (no bulky data on-chain), revealable whenever you want.

Use: protocols/assets on Bitcoin (Taproot Assets, etc.).

Now come the uncomfortable questions.

Do you think spammers will use op_return if it is four times more expensive than witness? Do you think spammers will act in good faith as Core assumes? Since when do spammers act in good faith?

And here's the key: Core has given up on fighting spam, it doesn't run filters on Witness, so why run any kind of limit on op_return?

OP_RETURN is a general policy change. OP_RETURN is just one more thing, in the same way that Knots comes with permitbaremultisig disabled and Core has it enabled.

Currently, Knots filters more than 98% of transactions, while Core no longer filters anything.

Neither violates the consensus rules; they simply have different policies.

So the final decision rests in the hands of the users, knowing that the filters do work, although their effectiveness depends on the percentage of nodes that run them. The more nodes, the more effective they are, but even with 20% of nodes running the filters, as is currently the case, a percentage of spam transactions are not mined.

That said, not running filters and removing the op_return limit opens up new attack vectors.

Perhaps the biggest problem is the campaign of lies that the entire core environment has orchestrated, and obviously one has to wonder who benefits from this.

Did the filters do any harm? Of course, now they will come up with the excuse of compact blocks and mempool homogenization.

Two questions: How can KNOTS block jpegs going into taproot witnes data? And what is your source for "KNOTS blocks 98% of transactions"?

The proposal seems to be:

* If a transaction contains illegal content, rather than relaying the transaction content, relay a ZKP which proves the transaction was valid without revealing the content of the transaction.

* This is TECHNICALLY a hard fork, because without the actual content of the transaction, the block shouldn't be considered valid. The definition of valid is expanded to include transactions for which a ZKP is provided.

* This doesn't necesarrily cause a split in the network. Nodes using the ZKP would see blocks from nodes NOT using the ZKP as valid. But nodes NOT using the ZKP might consider blocks not containing the original transaction. But presumably they could get the original transaction from another node.

* There is a censorship risk, since the ZKP only proves the transaction was valid, not that it actually contained illegal content. So if nodes running NOTS recieved a directive to replace a particular transaction with a ZKP, they would stop relaying it.

* Presumably it would only apply to OP_RETURN transactions.

nostr:nevent1qqstguh9pk9kvvucdh4wuvchflgwlqjkhsq6a6afp0r59urehqmjpksprpmhxue69uhkummnw3ezumr0wpczuum0vd5kzmp0qgs9wsu887m90qrxeug5p2wnrcmglddtsjlc4dys0uh62rgw442u0sqrqsqqqqqp36ny9h

Sup dawg? I heard you like parititions so i put a btrfs subvolume in a btrfs volume in a logical volume in a volume group in a physical volume in a luks partition in an mbr partition on a hard drive so you can split while you split while you split while you split while you split while you split.

Nobody wins in a civil war.

I wonder whether it increases at above or below inflation. It should be below the "true" inflation rate due to technology improvements, but regulatory capture may have cancelled it out.

I'm not doing anything personally besides discussing it. The limits really are a joke though and don't actually prevent anything from making it to the blockchain. It just limits what your own node will forward via the P2P network.

Arguably it could force the attackers to spend more money on getting their data in, and hopefully run out sooner (which is the inevitable result of any spam attack on bitcoin).

I have nothing against NOTS and would considering even running it myself. My problem is just the framing that core is somehow intending to "allow spam" and intentioally trying to destroy bitcoin. They aren't, it's just a different cost/benefit analysis.

If it's in the blockchain, you will be hosting it too unless you prune them. Which would be a lot easier if the attacker used OP_RETURN.

It's not really censoring. You are free to route or not route whatever payments you like on your own node. In the same way you are free to delete notes you're not cofortable with hosting from your nostr node. The network is free to route around you (and probably will).

Why would you deface a decades old symbol of acceptance and celebration of diversity with a corporate backed political symbol?

How the fuck do we keep falling for this?