pull down to refresh

Gmax's theocratic populist sex prohibition analogy for filters groups.google.com/g/bitcoindev/c/o3JZhiOa2PQ/m/xP0N_PvSAQAJ

1642 sats \ 23 comments \ @Scoresby 12h bitcoin

Well, it seems that someone proposed a "modular mempool/relay policy" on the Bitcoin Dev Mailing List

This BIP proposes a standardized mechanism to validate transactions for mempool acceptance using external scripts. Nodes load a directory of JavaScript (ES2020-compatible) scripts that define acceptance rules. Each submitted transaction (or transaction package) is passed through the configured scripts; if all scripts return successfully, the transaction is accepted into the mempool. If any script throws an error, the transaction is rejected. This framework allows flexible policy development without requiring changes to the node implementation.

To which Greg Maxwell responds

And then, of course, the inexhaustive Chris Guida joins the chat

But then Maxwell presents this beauty:

This bit is good:

The fact that a mechanism isn't proposed here just obscures the matter because one will arise out of necessity (or, alternatively, the proposal would just not be used to a meaningful degree). In essence the proposal (or ones like it like the one being developed in knots) are technological instruments of authoritarian censorship. Sure they don't have all the components yet to complete their natural conclusion.

As is the point about defaults

Why doesn't core ship blocks only? Core attempts to model what will get mined. My blocks only recommendation was for parties that prioritize conserving resources or avoiding various unconfirmed traffic over accurately modeling what will get mined.

The mailing list is good reading.

view all related items

309 sats \ 2 replies \ @optimism 2h

Core attempts to model what will get mined.

I still feel that this is a bit new-ish of a narrative though, afaik it was b10c that started analyzing cmpctblock reconstruction at some point. It is okay that the narrated purpose of the mempool shifts but perhaps this is the difference between what Core does and what Knots aims for, and all that is needed is coexistence.

I'd argue that:

Core is heavily LN-influenced and LN benefits from as-uniform-as-possible mempools between the sum of all miners, and your (watchtower) node. However, since there is no consensus over mempool, any limiting policy doesn't work (for a watchtower). LN is basically a zeroconf protocol, see this 2015 email on how policy messes with zeroconf, and then think about how Peter could analyze what happened with his modified nodes (2 replies below in that thread). The idea then becomes: Not relaying any transaction will be bad for other watchtowers, so as a community, the greatest value is the dissemination of transactions, so that everyone's watchtower knows everything.
Knots isn't LN-oriented at all, but instead focuses on L1 and community values. Nodes relay transactions and the operator is in charge of what to relay, and there are people that do bad things, such as shittoken mints, that make the network more expensive to run (and make it more expensive to transact.) The idea: It's in everyone's interest to try to keep this shit out, no matter the cost.

These are the opposing views. No ridicule is needed. Both views are valid and funnily, if we give up on the uniform mempool idea, and optimize implementations for the usecase we desire, yet can bring up the intellectual honesty that not everyone is in the same camp, then there doesn't have to be a war, at all, if people get their dumb doomscrolling butts off X and instead spend time building tools for their community to co-exist with the other.

The polarization is the problem, not the different ideologies.

0 sats \ 0 replies \ @Scoresby OP 6m

we give up on the uniform mempool idea, and optimize implementations for the usecase we desire

It seems like the debate has become intractable because in addition to the base disagreement about the effectiveness of filters, there is also a debate about how to decide on controversial changes to the reference implementation. Core does not seem willing to merge a PR they disagree with and Knots does not seem solely content with building in the Knots repo. So polarization happened because both sides feel like they have "ownership" (probably not the right word) of the reference implementation.

I appreciated @flaco's take on this from yesterday (#1234973), and would be very interested to read your thoughts in response.

LN is basically a zeroconf protocol

This feels like one of those high-density statements the unpacking of which leads to a lot of learning on my part.

I'll spend more time on it, but from what you said and the attached mailing list thread,

Is it that everyone's watchtower needs to know everything, or that everyone's watchtower needs to know miner's mempools? In the thread Todd says that the double spent txs had "were highly relayable/minable" but that the problem was that Shapeshift relied on something that used percent of nodes to which a tx has propagated as a proxy for confidence. This makes me think that the entire relay network can be the same, but if miners are willing to mine nonstandard, zero conf won't be reliable.

But all that aside, I'm still trying to figure why LN is a zero conf protocol: in the case of uncooperative channel close, first one to get a tx in a block wins. But what about penalty transactions? Don't they mitigate this?

Or is LN like a zero conf protocol because I don't really have my sats till I return to the chain?

I think I still don't have this fully in my mind, but I don't mean to take up your time with it (more just writing it out for the practice -- I'll spend a while on it and see where I end up).

0 sats \ 0 replies \ @TheCharlatan 10m

I don't think it is that new, but you are definitely correct that lightning helped shaping it into that direction. What do you think its primary purpose should be?

207 sats \ 17 replies \ @SimpleStacker 11h

Yikes!

Greg really jumped the shark with that analogy. He should've explained more thoroughly why variance in what traffic gets relayed can damage the function of the network, something I could reasonably agree with.

Instead, he went on some wild tangent about theocracies as a response to someone simply wanting more options. (I suppose his point is that those options can be used for censorship; but that's kind of like saying guns are bad because guns can be used for bad things.)

Sad that social competency and technical competency aren't well correlated, and indeed sometimes appear to be anti-correlated.

335 sats \ 14 replies \ @Scoresby OP 11h

its [your mempool's] purpose is to model what will get mined.

It really all comes down to this. Are you running a mempool for yourself or to attempt to exert control over other people's transactions?

If running for yourself, blocksonly may be what you are looking for.

If you are trying to exert control over other people's transactions...then: theocratic populist sex prohibition.

Meaning no sarcasm, I think the analogy works technically, and is humorous (although doubtfully intended to be), and probably should have been more concise.

I'm not sure if the filter side understands this, but my concept of their argument is that they imagine running a filter can somehow influence the type of transactions that end up in blocks.

If this is true, then, the action intends to have control over other people's actions.

If not true, then why have the argument at all? Run blocksonly and you achieve your goal.

207 sats \ 11 replies \ @SimpleStacker 11h

Are you running a mempool for yourself or to attempt to exert control over other people's transactions?

I dunno, I think that's a huge stretch. If I hear some information and choose not to relay it, am I trying to exert control over other people's thoughts? I think forcing me to relay is trying to exert control over my speech. People are free to get their information from someone else, I am not stopping them from doing that.

I'm not sure if the filter side understands this, but my concept of their argument is that they imagine running a filter can somehow influence the type of transactions that end up in blocks.

I agree that running a filter is probably not gonna influence what ends up in blocks. And that it could incentivize side channels and all that.

IMO Core should focus their arguments on why relay filters are bad for network functionality.

135 sats \ 10 replies \ @Scoresby OP 11h

If I hear some information and choose not to relay it, am I trying to exert control over other people's thoughts? I think forcing me to relay is trying to exert control over my speech.

You have definitely hit on the point people are disputing!

am I trying to exert control over other people's thoughts?

I never said anything about thoughts. I said transactions, particularly transactions that end up in blocks.

If you don't want to see such transactions in your mempool, it doesn't make a whole lot of sense to operate a mempool that will be fairly different from the next expected block. So, run blocksonly.

If blocksonly is not a good solution for you, why? Is it because you would like to run a useful mempool? Then you need to have as good a view as possible into the most likely next block.

If you want to participate in transaction relay because you believe it may have some influence what ends up in the next block...then theocratic populist sex prohibition is not a huge stretch.

Thoughts?

203 sats \ 6 replies \ @SimpleStacker 10h

If you don't want to see such transactions in your mempool, it doesn't make a whole lot of sense ...

If blocksonly is not a good solution for you, why? Is it because you would like to run a useful mempool?

The thing is, it shouldn't matter to you, or anyone else, why I choose to relay some data and not relay others. Whether it makes sense or not is beside the point. It's my right to choose what information I want to share and what I want to keep.

I really think Core-proponents are gonna dig themselves in a deeper hole if they keep using this line of reasoning, essentially trying to claim that they are the anti-authoritarian ones, while simultaneously being the ones trying to take away options.¹

They should just be up front with it: "From a technical point of view, we think inconsistent mempools is bad for the network, so we want to limit that option. If you need those options, you're free to choose another implementation, but in our view if a significant number of people did that, there will be (A) and (B) bad downstream effects."

I think niftynei did a good job in her recent post explaining this, that you actually pointed to (#1227437)

Look, I understand their point of view, on how filters are an attempt to stifle the propagation of data (i.e. a form of censorship). But it's a very tortured form of argument because the choice to not propagate data in Knots' case is an individual choice and not a forced choice. At the same time, the decision to limit people's options feels like a forced choice coming from a centralized authority (Core). Thus, I don't think Greg Maxwell's line of reasoning is gonna resonate with most people. ↩

105 sats \ 5 replies \ @Scoresby OP 9h

The thing is, it shouldn't matter to you, or anyone else, why I choose to relay some data and not relay others... It's my right to choose what information I want to share and what I want to keep.

Uh, yes, but it is not your right to tell someone else to make the tool available to you and maintain it for you if they don't want to do that.

People should run whatever software they would like to run. If you want to continue to have an OP_RETURN limit, run Core v29. No one is stopping you from making the individual choice to do this.

Also, Knots exists and if there is enough community support, people will maintain that project in the way they like. This seems like a fine solution. I'm not sure I even see why there is an on-going argument, unless the people who want filters are not content with their individual choices and require others to run such filters as well.

1105 sats \ 2 replies \ @Scoresby OP 9h

However, I am persuaded by approaches like this from earlier today:

The only formalized governance structure that bitcoin needs is the agreement that we should optimize for maximum user agency, so that individuals can run nodes and enforce rules (#1235383)

And also by @schmidty's PR to undeprecate OP_RETURN.

I personally don't think filters are at all effective, so if people want them, I can be convinced that we should just leave them in and move on.

(I think the only reason I've come back to this debate, after avoiding it for two years, is that I really strongly react to the idea that consensus valid transactions somehow shouldn't be allowed. We all agreed to certain rules when we accepted bitcoin in trade. if people don't like those rules, they should be straightforward and argue to change them. But nobody is talking about changing consensus rules and so all this feels fake to me, and it irritates me.)

202 sats \ 1 reply \ @SimpleStacker 9h

People should run whatever software they would like to run

Agreed.

Knots exists and if there is enough community support, people will maintain that project in the way they like. This seems like a fine solution

agreed

I personally don't think filters are at all effective, so if people want them, I can be convinced that we should just leave them in and move on.

agreed

it is not your right to tell someone else to make the tool available to you and maintain it for you

Also agreed.

I'm largely on Core's side in this debate. I think they can deprecate datacarriersize if they want to!

I am only reacting to Greg's arguments, which I think are weak and probably even counterproductive for his cause.

Sometimes it's better to say, "Sorry I can't convince you, but we're doing it this way", rather than try too hard to make an unconvincing argument. Remember Satoshi's words, "If you don't believe me or don't get it, I don't have time to try to convince you, sorry."

view all 1 replies

0 sats \ 1 reply \ @fourrules 4h

I'm not sure I even see why there is an on-going argument

I don't think there is an ongoing argument anymore, it's just a bullshit slinging match, primarily from the Core side.

Calling people who don't want to relay CSAM theocratic authoritarians and making out that filters are a slippery slope towards censorship by denying the distinction between monetary and non-monetary transactions is just nakedly polluting the debate with misinformation.

Obviously you cannot deterministically distinguish spam from non-spam, but it doesn't have to be deterministic, nobody is arguing for that.

And either running knots is a threat to the network or bitcoin is not trivially vulnerable to state (even legitimately theocratic) MONETARY censorship. Which is it?

0 sats \ 0 replies \ @standardcrypto 12m

you're going to relay CSAM anyway, it will just be spammed in addresses and you'll find out in a few confirmations when it is too late to do anything about it.

freedom is ugly, Bitcoin is ugly, people are ugly.

But you know what is beautiful? The truth.

reply on another page

0 sats \ 0 replies \ @fourrules 4h

Also, is it theocratic to prohibit sex with a 4 year old?

0 sats \ 1 reply \ @fourrules 5h

it doesn't make a whole lot of sense

Bitcoin is built incentives, not the homo economics rational actor hypothesis. You try to fuck the network you get fucked. People will do what they will do. Some will passively relay. Others will make evaluative judgements. Bitcoin is censorship resistant as a monetary network due to orthogonality and the fact that if everyone together is trying to influence values on the network the aggregate result is that monetary transactions will always get through, but content will incur a cost (even if that cost is direct to miner fees, because the miner takes a risk that nodes won't relay the block fast enough for the longest chain to work in their favour). Bitcoin is not censorship resistant as a distributed database for so structured content.

If this is not true then bitcoin is vulnerable to sybil attack and monetary censorship as it is today, whether knots exists or not, because while governments don't have to resources for an effective 51% attack, they do have the resources to spin up millions of relaying nodes.

But this is new, a novel line of argumentation. Has this been a vulnerability all along, held in secret by an elite group of bitcoin insiders?

I'm calling bullshit.

0 sats \ 0 replies \ @standardcrypto 8m

it's not really novel, there are ways of dealing with a Sybil attack on nodes. basically web of trust.

there's a primitive version of that already baked in with the bootstrapping, everybody trusts Bitcoin core basically

if the Sybil attack gets really aggressive we may need to do better than that.

but it's not like no one ever thought of this. they thought about it... a lot.

0 sats \ 1 reply \ @fourrules 5h

It is legitimate, in fact desirable, that nodes want to exert control over non-monetary transactions.

It is not legitimate to exert control over monetary transactions, and if filters are a useful tool for sybil attacking the network then they always have been and always will be, and Core's opposition to them is pointless.

The truth is that when targeting the OP_RETURN limit filters can only be effective as a deterrent against non-monetary transactions.

0 sats \ 0 replies \ @standardcrypto 3m

then the filter advocates should be honest and also advocate for eliminating or handicapping op return at consensus level.

but if they were honest they would appear even more ridiculous because people are greedy and don't want to pay more in transaction fees than necessary because of some ideologica or sexual purity test, which fails anyway because you can't block CSAM if the state attacker or whoever has big enough budget.

"CSAM is ok broken up across mamy monetary transactions but not ok in an op_return' yup that's what the knots argument boils down to.

It's only convincing because CSAM is so disgusting that most people's brains shut down when the argument pops up. But it's a transparently retarded argument, to me anyway.

5 sats \ 0 replies \ @fourrules 5h

Wisdom and intelligence aren't correlated.

0 sats \ 0 replies \ @LibreHans 1h

Gmax was always socially... challenged

31 sats \ 0 replies \ @OT 10h

harmful to the system and promote centralization

So better just do whatever Core wants?

120 sats \ 0 replies \ @LibreHans 4h

its purpose is to model what will get mined.

Yeah, this is ridiculously wrong, and gmax should know better. One of the purposes of the mempool was so that nodes could build transactions, that stopped being correct more than a decade ago. Another purpose is to relay transactions, that's the whole "censorship resistant" part. Relaying transactions that are harmful for the network has never been a goal, until the core pivot.

That somebody somewhere somewhen added a fee estimation feature is irrelevant to bitcoin the network, at best it's useful for some people who don't understand fee estimation and RBF. That's when you need to "model" what will get mined.

Why doesn't core ship blocks only? Core attempts to model what will get mined. My blocks only recommendation was for parties that prioritize conserving resources or avoiding various unconfirmed traffic over accurately modeling what will get mined.

Footnotes