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.

Reply to this note

Please Login to reply.

Discussion

Bitcoin blockchain only for bitcoin financial transactions. Everything else got to go.

When you actually start to think about what a bitcoin transaction is, you realize how silly this statement is and begin to understand what Waxwing is saying.

If I just consolidate my UTXOs, is that a "financial" transaction?

What about when bitcoin had no monetary value? Were those financial transactions?

Bitcoin users have been embedding data into txns from the very first block. Are those "financial" transactions?

What about timestamps? Are those allowed?

It is a slippery slope when you start to dictate what transactions are allowed and which ones aren't.

This isn't about making sure hosting a node is sustainable. There are already size limits for both txns and blocks that keep ongoing storage requirements of hosting a node linear. What we're talking about is the fundamental ethics of whether or not certain transactions should be censored or not.

And then there are the very real consequences about what that censorship can do to the open protocol by incentivizing the use of private txn broadcast networks outside of the default mempool or incentivizing data storage in UTXOs which actually does make running a node and mining more costly.

Stop with the word salad. Dont bloat the shit with nonsense. 🤨

1) yes

2) yes

3) yes

4) yes

the tx’s in question today are clearly identifiable as data anchoring being their PRIMARY purpose, unlike all of these examples

You contradicted yourself by answering yes to timestamps.

yes well that’s what happens when you shotgun a reply after reading the first two questions, the point remains and this statement doesn’t counter it

also if you wanted to timestamp a tx with some or other use of OP_RETURN or something that could be a totally legitimate financial transaction.

the point is it isn’t that hard to actually look and apply judgment, and even when you do you can’t apply network-level consensus for your view, only update your mempool policy for your node

i’m not reading this without some explanation as to why i should or what to look for..

You've already made up your mind then.

all i was asking for was a “this guy is a core contributor and this debunks what you’re saying”.

i read it anyway because, no I haven’t made up my mind, and I am an honest person here who cares about this deeply!

i don’t know if I can agree that we are dealing with “honest actors” here.

the technical perspectives are correct but i’ve not disputed them, somewhere in my replies you could find my statement that I think the limit should be set to max by default.

the logic behind removing the option is not good enough imo.

I shouldn't need to say that. If you read the originating mailing list discussion that started the debate, then you'd know who Antoine is.

https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ

Yes, he's a bitcoin/lightning contributor and more.

Your original response was you acknowledging you responded before reading my post thoroughly. Now rather than clicking the link I provided that goes into detail the rationale for removing the OP_RETURN limit, you disregard it asking me to provide you reasoning for reading it. In doing so, you expose yourself for not knowing that the person who wrote what I linked to is the one that started the debate in the mailing list and thus have shown you also haven't read that discussion there either.

The logic for removing it is sound from a protocol perspective. Keeping the limit in place risks more centralization, more transactions moving to alternative relay networks, and more censorship. Both of which harms the network more than anything that would come from having no limit with OP_RETURN data.

"Honest actors?" Please, stop with that narrative. Pieter Wuille, Adam Gibson, Antoine Poinsot, Jameson Loop, Greg Maxwell, Sjors Provoost, and more...these are all highly respected developers in the community that have worked tirelessly to build bitcoin to what it is today. To insinuate they have nothing but its best long term interests in mind is unproductive.

sigh man get off your high horse..

you are nobody to me.

I am nobody to you.

you put a link here as a response with no context and I had no idea who it was from or what it was. I saw that antoine posted this on twitter and that’s when I read it.

i am not referring to core devs or contributors being bad actors. citrea et al, yes. Lopp has a conflict which is part of what started this all. he is also a shitcoin supporter generally so fuck him, sorry not sorry.

i agree the technicals are all sound. you can find my support for the maximization of the limit in various replies I’ve given, I will link them if you want.

it is the direction of the culture of the project that is in question for me.

I believe we are catering to bad actors on false premises, such as the premise that these transactions offer legitimate demand for block space.

In what way did the *proposed* change that was proposed on its technical merits alone not fit your desired "culture?" Conforming to your desired "culture" was never a requisite for protocol development. And you say I'm the one on a high horse?

Taking the freedom of choice away from nodes and centralising control over Bitcoin so that bad actors can add bloat ware to the blockchain makes no fucking sense man.

It's a bad idea

yes, actually. the project has a culture as all groups of people do.

having concern for its direction is a valid concern as a user of the software produced.

These "highly respected" developers you speak of are driving people away from Bitcoin and making it easier for bad actors to hurt the network.

It seems like a huge conflict of interest going on

💯

Anyone who fears UTXO set bloat IS bearish on adoption. What happens when everyone on the planet wants a UTXO?

Well, napkin math has from the start shown us that that is probably impossible.

Everyone having a key, that is included somewhere in the script, perhaps more possible.

Global state is an expensive thing, thinking 'everyone one the planet' can be provided access to expensive things a foolish ideal.

I'd argue even thinking in terms of 'everyone on the planet' is some delusion to begin with; it simply not how the world works, nor a mental position anyone can actually occupy...unless you think you are God?

There is so much between what is the current state and this mythical 'everyone in the world', a lot left still to fight for, even if this dream of yours is shattered.

OK. Do 10% of population.

How about this:

Will Bitcoin be of added value to the world if:

Every nation and multinational holds a UTXO?

Every province and large corporation holds a UTXO?

Every municipality, medium business and rich individual?

Small business...etc?

Etc?

I would argue yes to the first, more yes to the second and so on. Lets see how far we can push things, without undermining what made it valuable in the first place.

It's nothing to do with UTXO bloat. It is the ability to control what you accept as valid on your computer. The UTXO set expansion does have limitations but it is the height of arrogance to think you know what the future holds with any clarity.

The crux of the argument is:

If I can't "Code my own" implementation do I have the right to configure what my node accepts as valid?

If no, then why is it right that the Bitcoin Network "censors" Ethereum transactions as "invalid" they paid for space on the block in ETH, why does every node reject it?

The only answer with any ethical consistency with "A permissionless money" is allow nodes to filter transactions or not depending on their preference.

Filtering doesn't prevent valid tx's from landing on chain

I didn't say it did... Read again.

So why kvetching about configuration? It's a moot point.

You can configure whatever you want and it won't stop the spam

Not the point.

It is not. Configuration is HOW you know what consensus is.

Example:

If I give you the Option to choose between the colors red, white, and blue.

Then 20% choose white

10% choose blue

70% choose red

The overwhelming consensus is that red is the prominent color. But that doesn't mean you'll NEVER see blue or white.

But if I say:

"Here is your option, the color red."

You will never see blue or white no matter what people prefer.

Removing configuration is removing choice.

Configuration is not consensus. I can config whatever I want and consensus valid txs will still be in my bloclchain data and UTXO set

You are misunderstanding consensus in this context. Consensus is not something that will "still be in my blockchain data and utxo set" the nodes dictate valid. Miners offer candidates based on the CONSENSUS of the nodes they pull the previous transaction blocks from. Which is determined by the CONFIGURED ruleset.

I speak of technical context, the only one that matters for creating a timechain entry.

Also, miners get tx'snout of band all the time, you cannot prevent that and long term incentives will only increase private mempool usage. MARA's slipstream offers whatbstarted at TG DM's as a service with a UI.

If spammers pay the fee, spammers get in the block. This is economic reality. Policy or configuration changes won't change this incentive. It's called censorship resistance.

if every node policy is useless why do they exist?

Legacy script problems from what I can tell. Or

nostr:nprofile1qqs0m40g76hqmwqhhc9hrk3qfxxpsp5k3k9xgk24nsjf7v305u6xffcpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtcwc656e might know.

Otherwise we deduce it from code and comments.

"Standardness rules exist for three main reasons. The first is as DoS protection. Your peers on the P2P network are not identified and some transactions are more expensive than others to process. An asymmetry between the cost of sending you an unconfirmed transaction (which is very small) and the cost for you to process it creates a DoS vector. Another reason for standardness rules is to provide upgrade hooks for soft forks. Invalidating a type of transactions in a soft fork that was already non-standard for a while gives more guarantees that a non-upgraded miner won’t include a newly-invalid transaction in a block, making soft forks significantly safer to roll out. Finally, standardness rules have also been used as a way to nudge behaviour toward a less harmful approach, or to mildly deter certain activities. For instance by standardizing OP_RETURN outputs, or discouraging data storage back when blocks were not full."

https://antoinep.com/posts/relay_policy_drama/

Obviously you aren't reading what I write so, good luck with your spam. I will run the code I want to with filters.

And your UTXO set will continue to bloat as spammers fill the chain. Won't be me spamming but it will bloat nonetheless.

I won't be keeping them in nor broadcasting them from my mempool and I will not be validating blocks from miners outside of my policy set.

So you're forking off?

I haven't yet, I seem to be in consensus at this point. We'll see who gets forked. lol

he speaks in a "technical context" because thats the language his handlers have allotted him to strawman the issue.

#bitcoin is for bitcoin. which is money.

the rest is fucking noise and attack.

Boolean logic is a pretty simple language.

Valid is not standard. Policy is not consensus.

Guy, either you missed something I wrote or you are strawmanning my argument.

What is your end goal?

Lol, to have the most freedom of choice for the code 90% of Bitcoiners run at the moment.

Is that goal okay with you?

Knots already exists. The choice is up to the user now. Fwiw, I have a knots node.

Need more education. Mainly so people can understand the difference between CheckTransaction() and IsStandardTx()

Yeah, Coke and Pepsi exist so no one should complain when they take away the flavor variety because you can just drink Pepsi.

I agree. Branding and education matters

The fact that you don't see the sardonicism in my reply is troubling.

You're doing great at marketing

Not really. If UTXO set grows in addition to new users that's a problem.

UTXO set size is proportional to the number of users and the amount of arbitrary data. A transaction always destroys at least one UTXO but arbitrary data cannot be destroyed.

Arbitrary data lives an UTXO

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

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.

Great point

As a non technical person, the concept of being permissionless is very high on my list

Best take I've read yet.

boomerang 🪃 😆

The point of a node (and the software it runs) it to tell others on the network what transactions you believe are valid. If that opinion is dictated to you (by removing configuration options) it is no longer permissionless for those who cannot write their own code.

By definition your node's mempool is censorious of invalid Bitcoin broadcasts. That is why you cannot send ETH on the BTC network. Through your node's code configuration YOU decide what is and is not okay for YOUR node. The fact that you don't rebroadcast invalid (in your opinion) transactions is your right, to do with your computer.

If you believe that inability to write code makes Bitcoin (or anything else) not permissionless then it already isn't.

You might have to read the words I wrote again. I think you missed something.

This misses an important distinction. The permissionless nature of Bitcoin is already and indeed MUST be within a boundary of permissible transactions, as enforced by the nodes. Just because miners can't award themselves more than 3.125 Bitcoin when they find a block doesn't mean Bitcoin is not permissionless when a miner who tried to award himself 6.25 Bitcoin has his block rejected.

Permissionlessness is not lost by having code-enforced rules. It is lost by having rules which apply to some users and not to others due to a central authority who can arbitrarily decide who the rule applies to and when.

There is no attack on the permissionless nature of Bitcoin by those who don't want to relay the jpegs people want to save to the blockchain. All transactions are subject to the same standard by nodes running Knots. No picking and choosing who the standard applies to.

It should also be noted that there is a difference between who a rule applies to and who it affects. The rule that miners can only award themselves 3.125 Bitcoin when they find a block applies to everyone, no exceptions. However, it only adversely affects those who try to award themselves more and subsequently have their block rejected.

Permissionlessness requires only that the rules enforced by nodes equally apply to all users, not that all users are equally affected by the rule. Mempools that filter out large OP_RETURNs apply that rule to all transactions sent to them, without discrimination. Permissionlessness is unaffected.

I disagree. The rules can enforce protocol-level semantics, but not off-protocol semantics. As an example, if someone publishes an old Lightning state on chain, that is theft; nobody proposes stopping that *both* because it's ludicrously impractical and also because at base, the off protocol semantics of transactions, their meaning in the outside world is *by design* not the business of the base chain.

This is exactly what Satoshi's design avoids - "all the trust required to make it work". Which committee decides what is a jpeg and what is not?

Sure, and in this case, the protocol-level semantic is the size of the OP_RETURN, regardless of whether it is a jpeg or some other data. The point is, it has no effect on whether Bitcoin is permissionless so long as it is not enforced arbitrarily, such that some transactions with larger OP_Returns are permitted, while others are not. Therefore your argument that it violates the ethical principles of Bitcoin is invalid. All users and all types of data within the OP_Return are treated the same by Knots. It's not looking to see whether that data is a jpeg, just whether it exceeds the size limit.

You seem to be interpreting my post as to say it's unethical to run filters, or to keep a specific rule limiting resource usage. I'm only saying it's against bitcoin's ethos to look for ways to prevent data embedding because that's where you cross into policing what transactions are for.

Yes but the ethics are even simpler than that. It's a voluntary system. Whatever is voluntarily consented to by ALL participants as regards their own property, their own nodes, with sufficient information to understand what they are consenting to, is what is ethical, or rather, at least lawful. If the devs sneak this PR in and it violates what noderunners would go for if they understood it better, that is unethical. Silencing discussions because you assume that ethical considerations are irrelevant, that is immoral because you are fundamentally denying the reality of ethical considerations, and all denials of reality are immoral.

I wasn't even talking about that specific PR, though it is highly relevant. I generally ACK that, but I don't think it's very important.

But the topic of silencing discussion on fora like github, mailing lists, is completely orthogonal to this.

All seems interrelated to me.

this is not accurate, mempool policy is not a consensus rule for validity of tx.

filters don’t censor anyone.

they give node runners control over what tx’s they want to propagate from THEIR OWN NODE.

this is more of a property rights issue and the moral high ground is with the node runners

Filters, if the intention is not to create a momentum towards changing consensus, are pointless and also detrimental, a little bit at least, as Greg Maxwell explains here:

https://old.reddit.com/r/Bitcoin/comments/1kab15o/bitcoin_cores_github_mods_have_been_banning_users/mpou6xb/

this whole thing assumes these “transactions” are legitimate demand for block space and that is something I disagree with

What makes the whole thing wrong is banning someone on GitHub for expressing their views.

Separate discussion there; I'm focusing on the long term debate about embedding data.

I’m still learning from both sides so can’t help there. Please don’t ban me. 😜

... harder thing is to say no to feature creep .. staying true to the mission is the whole point .. other wise you are another opportunist .. who would perish sooner than a scattered cloud ..