Replies (58)
What’s the alternative?
Can we get the link to this?
AFAIK, the perspective I have heard, specifically from Gloria, is that the changes they make are typically towards reducing load on bitcoin node hardware.
If a node can more closely predict what txs will go into the next few blocks, then it can avoid spending resources validating txs that are unlikely to be mined, and when a block comes in, it takes much less time and resources to validate because idle time was used very effectively.
Now of course, that gives an argument for setting defaults, but I do agree that optionality should exist and potentially there could be a collection of common configurations to pick from to promote individualism.
I get that configurability breeds complexity, but for bitcoin, I think optionality is more important. At the same time, it might not be the responsibility for the core team to maintain optionality, as long as they don't block it.
Knots Bitcoin?
Core should just remove datacarrier altogether if they're being honest. its a shame because the fix from december '23 works just fine 🥲
this episode of "oh no Core, theres this whitepaper out there for another form arbitrary data storage, what should we do? its out of our hands😵💫, lets go tweak OP_Returns" doesnt make any sense.
Agreed. Mempool policy is a strong signal and we should encourage more from the nodes.
Can they be circumvented? Sure. Should their voices fall on deaf ears? No.
I think
@npub1ej49...ndrm has chosen his next target after mempoolfullrbf=1
Dec '23?
ive been running Core with pull request 28408 (match more datacarrying) for well over a year. before the discussion for the PR was closed, at taiwan bitdevs we applied this patch together as a way to show our attendees how datacarrier works (or more like why it was broken). some users even continue to use that version of Core in their nodes, even applying the patch up through v28/29.
the users understand how arbitrary data still show up on blocks and still go through the process om their own. the patch itself works just fine, i dont see why datacarrier should be removed if it is working properly.
i followed the recent mailing list discussion and i dont have any strong opinions on the implementations that choose to bypass existing restrictions. doesnt matter that much to me, but the PR you submitted removes a functionality node operators use and im a bit lost as to why.
i dont buy that removing restrictions will reduce utxo bloat, intuitively it makes me think the situation would be made worse
i dont have a random fancy whitepaper to kick off discussion like the ML, i can only ask whats wrong with fixing it <datacarrier>?
on a positive note, at least theres acknowledgement that datacarrier is dysfunctional. best of luck with your endeavors to remove it, id even prefer that result compared to doing absolutely nothing.
Excluding transactions, which will end up being mined anyway, from a nodes mempool is irrational behaviour. It leads to slower block validation and worse fee estimation, while offering no benefit to the node runner. Why should core waste resources to enable irrational behaviour.
100% agreed.
Running a node means choosing what you relay not serving miners blindly.
Sovereignty starts with your mempool.
Stay free, stay sovereign. 🧡🏴☠️
this moves away from the free market and moves toward a centrally managed economy.
bad news.
Can you help me understand like I’m a 4th grader - thanks 🙏
View quoted note →Sounds alarming.
But I am very sceptical when I see Peter Todd.
View quoted note →#nevent1qqs20s2emz0agnceqkl6f7f4dsxue7mrj3y9l77slsck25z38pvs97cppamhxue69uhkztnwdaejumr0dspzp3w5s9wzdcvw9stczvcqffkah2dfdf0h4au45w4kqmg34gg929r2qvzqqqqqqy55akxm
?
@Matthew Kratter can you do a video about nodes and stuff?
Thanks, it seems your previous link was read as a tag by my client
Bitcoin Mechanic
He attacks Bitcoin
This motivates a major change to Bitcoin
In the resulting discussion on github, he approves of this change (that is motivated by his attack)
If you point out this conflict of interest - no matter how politely - you will be banned.
@ODELL hope you're paying attention to all this
Is bitcoin cash closer to what bitcoin is meant to be? Minus the network effect?
If the mempool is not running a service for the miners to get the most profitable chunk of transactions, what is it about?
No, they changed the consensus rules for the miners over the users.
Also, there is no "what Bitcoin is meant to be" there is only "what exists and works".
That's not true and you know it. Nothing about this change disallows people from filtering stuff from their mempool. Straight up misinformation.
That's exactly what is proposed...
No
It’s about building consensus for valid transactions. I decide what is valid for my node and will not be upgrading to software that merges this request.
What mechanism is used for this consensus? If everybody has their own pool, how is this building consensus? My understanding of Bitcoin is consensus is built through proof of work and block validation.
What is block validation in your mind
The result of checking a block's validity in Bitcoin Core. This includes validating its header, merkle roots, and transactions, spending its coins, checking its coinbase, and protecting against duplicates.
The Bitcoin core team doesn’t decide what Bitcoin consensus is.
The users decide.
Since I use software with an OP_Return limit,
I will NOT be adding to the consensus that the limit should be removed.
You can choose to do that sure, just like many other users that choose to set the limit lower than Bitcoin core does by default.
The job of the node is to validate transactions according to their own policy. Not to blindly run any type of software any particular dev team tells them to.
I think you are confusing things here. Block validation does not have much to do with policy. Every node has to run the same block validation checks or risk inadvertently forking itself off, or getting forked off by an attacker feeding it a specially crafted block, and falling out of consensus. My choice as a user would be running Bitcoin Core, but I could also be running btcd, or libbitcoin, as long as they implement the exact same checks in their validation logic. Bitcoin Knots just re-uses the exact same block validation logic that Bitcoin Core does, so there is no difference there. We all have to apply the same logic, or risk falling out of consensus.
The difference that policy makes in the case where a Bitcoin Core and Bitcoin Knots client enforces different policy rules is that if a transactions enters a Bitcoin Core client's mempool, and is then included in a newly mined in a block, Bitcoin Core does not have to re-request the transaction from a peer and can validate the block with the transaction it already has. If Bitcoin Knots on the other hand does not have the transaction yet, it requests it from a peer first, and then validates the block with it. In the end, the result is the same. Both nodes validate the block in the same manner, persist the same block of transactions to disk, and have the same view of the set of unspent transaction outputs. Applying the same block validation rules is the consensus all nodes have to maintain with each other and policy does not really play into that.
It does if they are forced to use recent versions of Core if they merge the PR. Which they are not, unless they are lied to about the Core code. You should probably be a bit more clear, as should Mechanic.
That's just part of the broader consensus, and the most crucial part. Another part is the broader suite of tools within the software including the mempool policy and relaying options. What he said was not wrong.
There is no such thing as "broader consensus". There is consensus and there is policy. There is no fuzzy line in between them. Both are part of node software and policy at least being somewhat common between nodes is good for the health of the network to reduce latency and p2p traffic, but there is no consensus mechanism involved and it is not crucial. You can run a full node without a mempool at all. Maybe you are referring to what might be called the "social consensus" within the broader community of node runners to adopt similar policy rules?
This seems to be a semantic argument.
I’m sure you realize no one can force anyone else to run rules/policy/“consensus” that they disagree with. Even if they are bitcoin core devs.
The Bitcoin network is run by users. There is no leader
I agree with your last post here. The thinking of most core developers is that there is no point in maintaining an option that effectively achieves nothing. It is compared with a placebo. If transactions make it into blocks anyway, and there is no physical resource consumption downside, what is the point of keeping them out of the mempool?
Well I’m no expert but it seems to be that if ocean mines a block with a strict data limit, then on average it will drive big data transaction cost higher.
So yes it does matter imo.
Regardless, I am not in agreement that the current Bitcoin core software should remove the ability for users to set their own limit for op_return size
"Miners can just put malicious stuff in blocks, so disallow nodes from having any say over whether or not they can reject that stuff from their mempools."
Is that the fallacy of composition and division?
Fallacy Of Composition And Division - Definition & Examples | LF
Explanation and examples about the Fallacy Of Composition And Division fallacy.
I think Ocean's market share is too small to have an effect here, though obviously that might change. They also use a different client already, so why should Bitcoin Core maintain something that they don't even directly use?
What does that even mean?
I'm not sure what you are getting at here. Do you mind elaborating?
"They also use a different client already, so why should Bitcoin Core maintain something that they don't even directly use?" -?
The problem with the patch from the perspective of disallowing data embedding is that for it to be effective an overwhelming majority of nodes would have to upgrade to this patch. In the time where most nodes are not upgraded yet, the network will perform in a degraded manner, but data carrying transactions will still be relayed. If most nodes eventually upgrade, it is easy for the spammer to come up with a new script variation that is not covered by the current filter, which starts the entire game again. At the moment nodes upgrade very slowly. It usually takes years before a big majority of nodes upgrade to the newest version. You could argue that this is fine, and people will just be encouraged to update faster, but then you enter dangerous "auto-updating" teritory, which is against the core tenets of our project.
Oh, I was under the impression Ocean uses Knots exclusively. But I guess it could be relevant for people who would like to relay transactions to Ocean, or a Datum template provider.
Should add that I actually do support keeping the option to limit relaying these transactions.
what do you mean by 'degraded manner' for the network as a whole?
other than a lower availability of these spam transactions in any given set of nodes' mempool, it makes little no difference for a node that is enforcing existing policy which is the network at large. it would only be degraded for the participants that want higher availability of arbitrary data prior to the spam transaction getting mined which is even a smaller set of people than the people who actibely upgrade software and/or apply patches.
the argument i see being made is that fee estimation could be messed up, but the thing is that fees are up to the node. their ability to calculate fees on their own criterion of what to bid against is none of anyone's business and certainly doesnt degrade the rest of the network. the node knows whats best, assumptions on what a miner "might" include in blocks dont need to (and shouldn't) be forced upon them.
Not having transactions in the mempool that are being mined into a block degrades compact block resolution. This leads to slower block relay and a quadratic increase in p2p traffic. If you don't accept data carrying transactions that your peers send to you, you create a negative externality for them if they are mined, because they need to relay them to you again.
arent nodes running filters to impede this propagation as a way to marginally discourage behavior of relaying transactions not accepted by the wider network? thats the entire point, it works. why wouldnt expanding those filters to include utxo-bloat spam work also?
when a peer is relaying a bunch of spam to my node, my node basically treats that peer like a block relay. not my business that he sends those txs to me multiple times and not his business i refuse to forward along transactions. in the event where multiple chaintips appear, I'd prefer to relay that the block with more of the transactions ive already validated in memory over the one where theres transactions my node hasnt validated
We are also arguing on stackernews. thanks for the discussion and consistency.
I say it's a political issue at this point. bitcoin-core must stop appearing to support the forthcoming "built on bitcoin" shitcoins.
see NVK's comments to Livera
The PR should be rewritten after public discussion at the big conference coming up.
> arent nodes running filters to impede this propagation as a way to marginally discourage behavior of relaying transactions not accepted by the wider network? thats the entire point, it works. why wouldnt expanding those filters to include utxo-bloat spam work also?
I don't understand why you are saying this works. Clearly transactions are finding their way to miners over the regular p2p network. For what it's worth I also don't understand why this change is sold as company x needs this to post the data as op_returns. They should just do it now, because enough nodes and miners have these liberal policies already. Bitcoin Core should still adopt the relaxed policy to make relay smooth, and make it easier to use, because it reduces harm in terms of node storage requirements, but keep the option, so node runners like yourself can encourage building templates with non-data carrying transactions.
From a game theory perspective, this is an IPD (Iterated Prisoner's Dilemma), not a one-shot game—different strategies emerge, especially as the fee-to-subsidy ratio grows over time.
I have a feeling it will be. I'm usually not a mempool developer outside of getting its logic isolated from the rest of the consensus code, but I do care about data embedding too. I wrote my diploma thesis on the very topic.
apologies, my nostr-edit appears not not have made it to you: "arent nodes running filters to impede this propagation as a way to marginally discourage behavior relaying *blocks with* transactions not accepted by the wider network"
i think you mistake the occasional stunt by miners to throw random junk they choose to include in blocks as a failure of mempool policy. it'd be as absurd as to pointing to an empty block and blame it on mempool policy too
Thanks for reposting :)
My nostr client is really messing the rendering of this thread up right now. Maybe it's good to stop a discussion at some depth ^^.
My impression is the recent large OP_RETURNs are not a miner stunt. A stunt for sure given their content, but my impression is they get through by relay.
🤔, so which is it? you can have whatever impression you want but this works in a certain way.
are these larger OP_Return transactions successfully relayed through the network because a sufficient amount of nodes actively configured their node to do so (because Core or Knots wont do it out of the box save for Libre Relay and some very old versions) or are these transactions resorting to services like slipstream because the wider network wont relay them?
because if you're saying these transactions get through by a small subset of configured nodes relaying to one another, consider to extending that conclusion to nodes choosing to configure in another direction too 😅 and if you're saying these transactions had to be sent to the miner directly because the wider p2p network wont relay them, well...seems like you understand that filters work and that it costs something to get around them 🤷
Mmh, I think it is clear that if ~all nodes use the same policy a transaction has a tough time of getting through. Surely there is also a cost for getting around them too. But I think we've reached the point here where that cost is low, and the cost incurred by not adapting is bigger.
I also think it should be left configurable at least . Miners should get the choice of not having to include these transactions, meaning Bitcoin Core should allow excluding them from template generation. Similarly nodes relaying transactions to these miners should be able to exclude them to able to relay lower fee transactions that might get evicted otherwise if the mempool is full already.
