Replying to Avatar waxwing

What surprises me about the tech and developer discussion around embedding data onchain (and OP_RETURN is just a corner of that), is how little of the discussion refers to the ethics.

There's an obvious point, and an obvious (in my opinion, incorrect) counterpoint.

The obvious point is that permissionlessness is central to Bitcoin's nature, and that implies *ethically* you cannot tell people what kinds of transactions are OK, and what are not. There are very substantial *technical* arguments as to why it can't really be prevented, but they are secondary to the ethical one: you don't have the *right* to tell people what transactions they can do.

The obvious counterpoint is that posting anything to the blockchain has a cost for *all* users. That's why we spent 4 years arguing about the limit on the size of blocks. I have no ethical right to tell someone not to publish or mine a block of size 10GB, but it doesn't take long to realize that the costs this imposes on other participants, is too large. In case you think, this argument was straightforward, the big blockers were wrong, don't forget that the resolution, for better or worse, was a compromise: average block size today is often 2x the size before. It was a really difficult argument.

So the counterpoint wins and we have to discuss whether embedding data should be allowed? I say, no, this a fundamentally different discussion. It is not a discussion of *how much computational resource is used in total*, but rather a discussion of *what individual users are using the computational resource FOR*, and that crosses the line into being ethically unacceptable, unequivocally.

I say that the technical awkwardness, or even impossibility, of restricting this behavior in the Bitcoin system is just a byproduct of trying to make Bitcoin do the opposite of what Bitcoin was designed for - censorship resistance.

I also think that if you explore technical solutions that might _actually work_ (though also require people to spend their own money), rather than the current and proposed feel good settings, you quickly end up attacking the heart of censorship resistance.

nostr.

nostr:nevent1qvzqqqqqqypzpp59a0hkv5ecm45nrckvmu7pnk0sukssvly33u3wwzquy4v037hcqy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgewaehxw309ahx7um5wgh8xurjdamx7mmnwshxump0qqsyhn5s36xyw7rz602423vaz3f75wtxvxu6m7tfpnsg9vpmczqsa9cqxshlf

Reply to this note

Please Login to reply.

Discussion

Your idea of actively publishing which block you're censoring is interesting, and a bit headspinning. But before that step, what does "actually work" mean, to you? I start from a baseline that people could always embed data using witness data and xor, say, even inside completely standard transactions that are self transfers. Embedding into the utxo set with standard template scriptpubkeys (without OP_RETURN) is harder, but everything is possible at a high enough price.

If 'actually work' means censoring only easily distinguishable things like certain OP_RETURN s it seems fairly pointless to discuss? Maybe?

I should also emphasise the word "might", in contrast to the current proposals which certainly don't work.

The goal of the filter people is to censor OP_RETURN and inscriptions specifically. They have no rational basis for this, as you explained, but I'm just taking this goal at face value.

Without a consensus change it's impossible to stop the transactions from going through eventually, but you could try intimating miners into self-censorship. We know from human societies that a fairly small group of people can control a very large group at fairly low cost. A key ingredient seems to be to disproportionately punish offenders to set an example.

So if you can gather a few percent of hash rate that enforces these arbitrary filters through reorgs (N deep, depending on budget), some pools will experience noticeable losses. This then encourages them to be on the safe side and use these filters. Bitcoin Core might then have to adopt similar rules in order to produce blocks that are safe.

To be clear, this won't permanently censor these transactions either, but because not everyone is going to be sufficiently intimidated. But it will delay them more than in the scenario where those miners only exclude things from their own blocks. And definitely delay them more than can be achieved with just policy, even if 90% of nodes used these filters.

As the reference implementation, core should have “the best” policies from a genuine comp sci and networking perspective, not a commercial one.

Any major policy decisions should be handled at the fork level. Want more data carrier size? Fork it! The thought that this should be debated on github is laughable.

I would recommend Greg Maxwell and AJ Towns latest replies on the mailinglist. It's harmful if people use different settings, whether that's by configuration option (-datacarriersize) or by code forks (Knots). The chaos of a "free market" for settings is disruptive for the network, which only helps its real adversary: governments.

The custom Knots default of 42 bytes caused problems in the past for Samurai wallet (which they in turn used for their drama marketing). In theory it should also interfere with compact block relay (I haven't seen measurements though).

https://gnusha.org/pi/bitcoindev/aBSVn7nJnrheLy5Z@erisian.com.au/

It’s tricky to parse what disrupts the network from relay and miner perspectives. I can see a miner having to validate a block with transactions it’s never seen before to be a disruption, but for non-mining nodes I don’t see it as a problem.

For non-mining nodes, relaying/accepting transactions that won’t get mined certainly doesn’t make sense; nothing-at-stake mempool attacks are an obvious consequence.

All that said, perhaps the real issue here is analogous to the misaligned incentives leading to Napster: people wanted downloadable music and there was only one way to get it. It wasn’t until music companies stopped suing would be customers and started selling digital music did the issue go away.

With regards to what I said here:

> This then encourages them to be on the safe side and use these filters. Bitcoin Core might then have to adopt similar rules in order to produce blocks that are safe.

This would be a "nice" use case for what Greg Maxwell suggested today on the mailing list (and earlier on Reddit), to separate relay policy from mining policy - where the latter can be more strict:

> That said, Bitcoin core has generally not

had knobs to adjust relay policy as distinct from mining policy in large

part because of the design assumption that the two need to be the same.

But in this case if there were a knob here I think would make more sense

for it to control mining policy rather than relay policy, since it would

actually have some effect in the mining context (in excluding the txn from

your own blocks) while as a relay only thing it is impotent.