pull down to refresh
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.1
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)
Footnotes
-
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. ↩
reply
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.
reply
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.)
reply
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."
reply
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.
Fair enough. You have some wisdom there (even if I disagree with you about the weakness of the theocratic populist sex prohibition argument).
reply
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?
reply
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
Fragmented?
reply
Also, is it theocratic to prohibit sex with a 4 year old?
reply
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.
reply
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.
reply
Obviously they did. So why now is Greg freaking out about censorship and "theocratic authoritarianism"? Its ridiculous to suggest that filters for non-monetary transactions are a slippery slope towards censorship.
reply
IIUC, the argument is that the end effect of something like knots being popular is mining centralization. The mechanism of it is a bit subtle; I think pieter wiulle goes into it in his big post about why core lifted the op return restriction. (And it's repeated in many other places)
Let's see if I can recapitulate. If nodes can't predict blocks (same as predicting fees) then neither can small miners. So big miners have an advantage, because everybody is sending their "non monetary / spam" transactions to them. So eventually you wind up with a few big pools instead of pool diversity, and then it's easier for the state to impose its will on the big pools. Yeah I think that was the argument and it's convincing to me.
You might not like Greg's tone, he's definitely pissed, but that doesn't make him wrong.
You need nodes to be able to predict blocks / fees, and knots gets in the way of it. That's it.
Also lukejr is an authoritarian tool, but even if he wasn't you still need to predict blocks and fees. hashtag: Knots is the spam.
reply
The problem with this argument is that it reeks of a lab experiment, like these complex dynamics exist in a vacuum and will play out entirely as predicted, and that there are no possible countermeasures that could be deployed that would satisfy node runners who don't want to relay non-monetary transactions and who want to influence the quantity of spam that gets validated.
Greg is the authoritarian tool. Always has been, since I was arguing with him on Reddit in 2015.
Its time for knots and other implementations to get in the way.
reply
I think it's good to have more than one client, and am fine with people running knots.
With the current fee landscape, nobody will have trouble getting their transactions in a block, whichever client they use. As fees (hopefully rise), using knots will be seen by its own users as more and more of a hassle and a hair shirt, and they will gradually migrate to other clients that have a sane mempool policy.
Luke is a nuisance. Gmaxwell has his rough edges, but he doesn't have his minions spamming the knots git repo with pull requests and argumentation.
I guess everyone use the client they like and we just see what happens.
reply
It is not good to have multiple clients.
"I don't believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network. The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint." --SN, 2010
Bitcoin Core, the satoshi client, is fine.
reply
man satoshi said that but is it really true?
what terrible thing happens if nosea aren't in lockstep? the only thing I can think of is stale blocks (fork risk) and fees become hard to estimate. am I missing anything?
Good idea or not, SOMEBODY will try to mess up the network (or co-opt it for their own use) sooner or later. They'll either hack the existing code or write their own version, and will be a menace to the network.
I admire the flexibility of the scripts-in-a-transaction scheme, but my evil little mind immediately starts to think of ways I might abuse it. I could encode all sorts of interesting information in the TxOut script, and if non-hacked clients validated-and-then-ignored those transactions it would be a useful covert broadcast communication channel.
That's a cool feature until it gets popular and somebody decides it would be fun to flood the payment network with millions of transactions to transfer the latest Lady Gaga video to all their friends...
That's one of the reasons for transaction fees. There are other things we can do if necessary.
The problem here is that Core developers are actively stating that there is no such thing as spam, validity is the only criteria, which is a complete and explicit shift away from Satoshi's and the community's intention and understanding for 15 years.
Core developers are breaking the social contract, leading inevitably to the menace of multiple implementations.
The design supports a tremendous variety of possible transaction types that I designed years ago. Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc.
Nowhere here does he include jpegs, runes, or short videos. He could have, but he didn't.
The problem is that Core developers and their advocates here are lying about the distinction between monetary and non-monetary transactions, because we have been infected by shitcoiners whose own projects failed in the shitcoin distributed database market.
And Core is playing brinkmanship, extorting the community. Anyone who cannot distinguish spam from monetary transactions should in good conscience walk away from the repo until other developers step up, let it sit, let it go through a dormant period, until the dust settles on this.
By forcing the idea that bitcoin is just a distributed database they are creating the scenario where people invested in a monetary network have to fight to protect their investment.
Fees on their own simply won't outcompete spam on fees, not when lightning and other means of transacting bitcoin exist on L2. When there is a scarce resource (block space) people will create all kinds of competitions to exhaust that resource, as a sort of prize, a sorting mechanism.
blocksonly.blocksonlyis 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.