PR closed: datacarriersize: Match more datacarrying by luke-jr \ stacker news ~bitdevs

PR closed: datacarriersize: Match more datacarrying by luke-jr github.com/bitcoin/bitcoin/pull/28408

2976 sats \ 14 comments \ @niftynei 9 Jan bitdevs

Controversy aside, I thought how luke-jr went about making this change was incredibly sophisticated.

He adds a counter that considers bytes after the OP_FALSE OP_IF in a script* as "datacarrier" bytes.

Why I think this is sophisticated: the concept of 'datacarrier' bytes is not new to bitcoin. In one light he's 'updating' the existing semantics for new ways people have figured out to add data to the chain.

What I like about the design: it's elegant because it hooks into an existing paradigm in the codebase, in a way that's arguably (emphasis on arguably here) correct. Like yeah, that's a reasonable position to take.

He then adds a check that rejects txs with inputs with scripts that are above the 'datacarriersize' limit. This is also quite clever. I think that most nodes already have this number set, and so pushing this change out would have a dramatic impact on uh, let's just say a certain class of transactions, almost immediately as nodes upgraded.

fwiw I strongly agree with Peter Todd that this is sub-optimal from a protocol design perspective, as it will encourage "motivated blockspace buyers" to find other, out of band, ways to get their transactions mined. https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1735079576

*and also data added via OP_PUSH / OP_DROP

view all related items

571 sats \ 0 replies \ @Murch 9 Jan

I think that most nodes already have this number set, and so pushing this change out would have a dramatic impact on uh, let's just say a certain class of transactions, almost immediately as nodes upgraded.

Many people overestimate the impact of policy. Transactions will propagate through the network if a small portion of the network accepts them. I'm the context of the mempoolfullrbf debate my colleagues calculated that about 5% of nodes adopting it would suffice for the majority of non-signaling replacements to make it to miners.
The Bitcoin network if very different to the Lightning Network in so far that fewer than half the nodes are running on the latest version. In this case specifically, inscribers and miners would have an incentive to simply not upgrade. The main effects of upgrading about half of the nodes to this would be that that block propagation slows down, because many nodes have not seen all transactions in advance and that feerate estimates would be low on those nodes.

Additionally, as miners upgrade, they will earn less fees to the benefit of miners that don't filter.

I also left a nack in the PR with a longer explanation here: https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1878746998

143 sats \ 0 replies \ @9ener1c 9 Jan

Just like in virology where a vaccine that doesn't completely block infection causes potentially dangerous evolutionary pressure, a fix would neeed to be (near) absolute.

269 sats \ 6 replies \ @ek 9 Jan

I just realized that the controversy around inscriptions feels a bit like the War on Drugs.

It's pushing people we don't like to the edges of society (and beyond) and then we tap ourselves on the shoulder that we "solved" the problem but actually are making the situation around drug usage worse for everyone involved (including society itself) but we deny reality since we like easy "solutions".

I wouldn't recommend doing drugs to anyone but if someone does drugs, I will also not tell them that they are using life wrong. It's their life and their consequences / problems.

Haven't though too much about this similarity so if someone thinks that's stupid, please tell me so lol

571 sats \ 4 replies \ @nerd2ninja 9 Jan

Yeah this thinking is basically what moonsettler calls the "Evil mempool" scenario. We sort of saw the scenario play out with Full RBF (https://mempool.space/rbf) where even though it isn't a default setting, even though you need to run a custom client to peer with other nodes that don't ignore your full rbf txs, we still see a full rbf txs get mined and frequently.

Core's development objectives have always been to never merge anything that doesn't have full consensus (even with mempool policies) because they don't want people routing around them (like full rbf people are doing right now...they should really merge that PR lol) and so that's a huge part of why (more specifics in the PR comments you can read obviously) they locked this thread.

Now to be clear, I'm still very much on the side of prioritizing financial transactions over this noise, but for technical reasons, I prefer to look at increasing costs for undesirable behavior and making cheaper the desired behavior, because that's what's actually going to work.

1323 sats \ 1 reply \ @petertodd 9 Jan

even though you need to run a custom client to peer with other nodes that don't ignore your full rbf txs

Nitpick: that's actually not necessarily true right now. There's enough people running really well connected full-rbf nodes that a node that accepts incoming connections has a reasonable chance of being connected to a full-rbf node.

But certainly, if you want your full-rbf txs to be guaranteed to propagate, run this: https://github.com/petertodd/bitcoin/tree/full-rbf-v25.1

I'll have a version for v26 soon too.

0 sats \ 0 replies \ @nerd2ninja 9 Jan

lol thank you for the update

0 sats \ 1 reply \ @netstatic 9 Jan

I don't believe there's a way to do this without crippling other use-cases focused on scaling (like BitVM). The best way to do this imo is to teach those who don't like inscriptions to change their policy to disallow transactions with large scripts from being relayed to their mempool.

4 sats \ 0 replies \ @nerd2ninja 9 Jan

Yeah so one thing some people I know are talking about is like, increasing the cost of scripts. So that would be making the vbyte weighting for segwit space to be closer to the weight for the utxo set space, but not exactly the same weight for example.

Ultimately though, the real killer way to do this is to have 100 users share a utxo (L2 scaling solution) and each user pays 1 sat vbyte to exit and that becomes a 100 sat a vbyte tx on-chain that serviced 100 people. That's gonna take years and years to develop all the things we need to get to that point, but that's the ultimate direction.

293 sats \ 0 replies \ @xz 9 Jan

Interesting. Thinking bout this..

Transaction types: Standard data transaction, ordinals and inscriptions.

Bitcoin Markets. Exchanges and P2P

Drug Classification: Narcotics, pharmaceuticals, base chemicals, naturally occurring psychotropics, complex synthesized compounds.

Distribution: Cartels and P2P

Reception. Is regulating or deregulating welcome among network participants?

Deregulation of controlled substances: Benefit to buyer

Unwelcome for a drug cartel (pricing has to be competitive) Encourages a higher quality of product Lower cost to user.

Deregulation of block space

High fees welcomed by miners Encourages lightning and L2 usage (minimizing L1 transactions)

185 sats \ 0 replies \ @ek 9 Jan

I also liked the comments from Sjors:

NACK. There's no universal way to filter all present and future datacarrying styles. This invites an endless cat and mouse game inside very critical code paths.

It seems better if you just keep this patch for Knots, or alternatively, come up with a generic design to filter transactions. E.g. by loading rules from a file in some template language.

-- https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1842754101

Just to set expectations, I might also NACK such a generic arbitrary filtering system, given the can of worms it would open, but I'd have to think about that more.

-- https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1842759347

Especially this one:

This does not meet the bar for "good". If only Ocean pool uses this and it remains a relatively small pool, it will have no effect. If it is widely deployed, it's trivial to circumvent, which will cause this code to grow in complexity. And every time that happens there'll be a lot of pressure on maintainers to push it through quickly "to stop the spam". It's just a matter of time before some DoS vector accidentally makes it in.

For example you're currently looking for this pattern, used for inscriptions:

OP_FALSE OP_IF spam OP_ENDIF This pattern fits about 1000 data pushes with each a max of 520 bytes, so 520 KB, per output.

If this PR were widely deployed, the pattern could be changed as follows:

OP_TRUE OP_IF spam OP_2DROP … OP_2DROP So the "spammers" now need to use up to 500 OP_2DROP codes so the stack is empty again, reducing the capacity to 515 KB. This time the code is actually executed by nodes, which is (slightly?) worse.

Next move?

-- https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1844981799

I think Sjors arguments can also be reframed as this PR giving a false sense of security but actually making things worse.

21 sats \ 0 replies \ @ZezzebbulTheMysterious 10 Jan

I hate the barbarian spammers, but we can’t filter transactions based on a template. The barbarian will alter its tx encoding format in spite. The spiteful cannot to routed by static filters.

The problem is systemic, and must be dealt with culturally. Technical solutions based on tx template denylist are as effective as AntiVirus in the 00s.

0 sats \ 1 reply \ @kristapsk 9 Jan

IMHO if you agree to arguments against this change (configurable setting), you might as well just drop -datacarriersize. Yes, you can't prevent miners from mining Inscriptions, but same applies to larger OP_RETURNs too.

21 sats \ 0 replies \ @netstatic 9 Jan

It's just not a very intelligent solution. I'd rather he make a new setting for witness script sizes rather than using the existing datacarrier setting and looking for envelopes. The people who disagree think it's pointless to single out inscriptions because there are so many other ways to store data.

See the PR comments linked by others on this thread*

0 sats \ 0 replies \ @rijndael 9 Jan

very clever implementation. I think it would be nice as a new option.