datacarriersize: Match more datacarrying #28408
Conversation
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code CoverageFor detailed information about the code coverage, see the test coverage report. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. ConflictsNo conflicts as of last run. |
Github-Pull: bitcoin#28408 Rebased-From: 4465872
…root Github-Pull: bitcoin#28408 Rebased-From: 1a0a1d3
Github-Pull: bitcoin#28408 Rebased-From: c49ed98
Github-Pull: bitcoin#28408 Rebased-From: 4465872
…root Github-Pull: bitcoin#28408 Rebased-From: 1a0a1d3
Github-Pull: bitcoin#28408 Rebased-From: c49ed98
|
Maybe I'm doing something wrong but it will seem that my node no longer receives any txs with this update if |
Do you have any suggestions to fix this? |
|
@MarcoFalke @glozow |
There was a problem hiding this comment.
I pushed some unit tests to https://github.com/LarryRuane/bitcoin/commits/2023-09-luke-DatacarrierBytes-test (only the latest commit). It looks like some functional tests are failing (p2p_segwit.py, at least), and there should be some new functional tests for this PR. I'll try to do that over the next couple of days.
|
Concept NACK The transactions targeted by this pull-req are a very significant source of fee revenue for miners. It is very unlikely that minres will give up that source of revenue. Censoring those transactions would simply encourage the development of private mempools - harmful to small miners - while making fee estimation less reliable. |
|
Concept ACK The transactions targeted by this pull-req. are a very significant source of prohibitive cost for regular node operators. It is very unlikely that regular node operators will give up mitigating that source of operative cost. Regular policy rule for these transactions would encourage the economical resource usage of mempools - not harming any miners - neither changing any fee estimation already on the field. |
As long as miners continue to mine these transactions they will end up in blocks, requiring node operators to process those transactions. Censoring those transactions simply shifts when that bandwidth usage happens. Indeed, it'll make block propagation happen somewhat slower for some users/miners due to interference with compact blocks. This is harmful to many users, as well as some smaller miners. Secondly, fee estimation requires knowledge of unconfirmed transactions to determine what the next block will likely consist of. Censoring unconfirmed transactions that could be included in blocks makes it harder to estimate fees correctly because you lack information about the true total demand for blockspace. |
There is not censoring of anything. Focusing to propagate that framing is just misleading and dishonest. Miners entities will propose any block which complies the consensus rules; it was so since the beginning, it is so and it will remain so. Nothing has changed, nothing will change. If block propagation after consensus rules validation may slow somehow then that would be the cost internalization for mining entities proposing blocks with transaction which increment prohibitively the operation cost for regular node operators. There are already many mechanisms to increment the fees from an already broadcasted transaction (nobody probably knows that better than the RBF’s proposal author). Furthermore, there is not something called “demand for blockspace”, what there is, is a fee bidding for transaction processing in a timely manner; a compensation for mining entities for losing relative competitiveness with each marginal transaction inclusion. |
False, I let you compare these two instances of the mempool software you will see that the fees are rarely incorrect. https://mempool.space
You are mistaken about the purpose of this PR, the goal is simply to apply the same restrictions as on OP_RETURN.
Probably false, mining pools require exorbitant fees to mine a tx out of the mempool, thus making the "mint" of "BRC-20 tokens" unprofitable. He will therefore stop having demand for that. |
|
Concept ACK These transactions affect the decentralization of the network by increasing the cost of operating the nodes, which are without any added value for bitcoin. |
Your bias is more than clear, I wont be listening to ideological BSV logic. If you have a serious response you are free to post it, but purely ideological biased comments are completely antithetical to our reason to be having this conversation in the first place. And for a hint on how to lie better in the future, unbiased people don't have to go around announcing their unbiased status. They simply do not have alterior motives. |
No it literally is not. They are convincing new and uniformed users that there exists such a thing as satoshis that are more rare than other satoshis. Not only is this completely false and a scam, but if legitimized even a little bit would completely destroy the value proposition of anyone unfortunate enough to encounter this as their experience with Bitcoin. Other protocols sell cheaply random generated JPEGs that are not even owned by the recipient in any realistic way, they are totally public domain. Another scam. If you cannot see how this makes Bitcoin look like a scam and not money to be taken seriously you should feel sick to your stomach. |
I don't know what this insanity is, that you are replying with. I wrote a detailed response to explain how Bitcoin actually works in the real world, instead of in an idealistic fairytale world, and you cherry-picked one piece of it to reply to with nothing constructive, and somehow you thought this was acceptable? If you're not interested in a proper conversation, that's your prerogative, but don't suddenly make insane ad-hominem baseless accusations (BSV, really, could you not go any lower?), and then expect to be taken seriously after such a display. |
You are quite literally word for word repeating talking points made by BSV users who intend to harm Bitcoin by spamming the UTXO set and creating an unreasonably high fee environment in which the average end user is incentivised not to participate or if so forced into a custodial solution from which their Bitcoin fails to actually be a bearer instrument. https://www.youtube.com/watch?v=-RswZDQTqsI All the connections were made by a random pleb in this video, don't think that because you pretend not to notice or actually are dumb enough not to notice that we wont. We notice the connections. |
|
Furthermore you have made so many straw-man arguments in your response that I can only consider it an insult on the face of it, if anyone seriously holds any weight to the complete misrepresentation of my points you made in the future I will respond to it in full detail. |
I don't care what BSV people say, and I don't listen to them. Go argue the points themselves, if you can, don't argue based on who makes which points.
Inscriptions don't do that, unless you mean STAMPS or something else. And UTXO set increase affects pruned nodes' storage requirement (not RAM, as is commonly misstated on Twitter), and based on conversation with some, only minimally. Regardless, they can pay less by using Inscriptions, yet pay more because they hear threats/antagonism from others to try to filter inscriptions, so they get worried. That's the whole point of the argument that was made all the back in Jan 2023 by Poelstra, and previously by Casey, that op-return is the best way to do it, and interfering will worsen the issue.
Then support efforts to actually scale Bitcoin, like improving layer 2 LN and ARK via efforts like CTV and/or other covenants proposals, and improving efficiency of layer 1. I already addressed this point. This PR's filter change is a larp. Broadly though, as I explained in a prior post to someone else, the txs where it is not economic to pay the tx fee can still be made if using layer 2 like LN (and sidechains like Liquid, with the new Aqua wallet recently released). So the problem is far overstated, and would be the case even if the bull market arrived and caused a big spike in tx demand and thus tx fees. So this is not unique, and it is not unsolvable, and it can be improved by focusing energy on actually scaling Bitcoin.
Yeah, typical conspiracy theories, and conspiracy theorists always sound the same (but sometimes they are right). We already had such behavior from bcashers during the block size controversies of the past, and they were famous for becoming deranged because they ended up on the wrong side of reality (sound familiar right now?). The conspiracy theory arguments basically revolve around guilt by association, speculation, misunderstanding, catastrophization, correlation vs. causation fallacy, etc. But I'll add that if BSVers are serious about wanting to push for a block size increase fork on Bitcoin, then most people in my camp (like 99%?) will obviously be 100% against it. So it's not a real concern. Bigblockers think they are harming bitcoin because they don't understand how bitcoin works (since they supported big blocks vs. the small block design that bitcoin has). I saw another video where a BSVer is gloating about the fee increases and saying he is spinning up projects to build on bitcoin, but he showed he doesn't understand bitcoin's small-block design and how and why it works. And whatever involvement BSVers have with the arbitrary data protocols ecosystem is not something that can be prevented. It's obviously a free market. And Udi trolls a lot as a marketing tactic, then some take him literally and seriously and miss the joke. But if he also pushes some contentious fork, then it's the same story, it would be evaluated on merits, not blindly accepted obviously.
Go prove it, don't make things up because you lack arguments. I tried to directly respond to specific arguments, while also providing extra related information. Maybe you don't understand what strawman argument means.
Nah. First of all, what you are referring to here is "ordinals", which is a collective hallucination Casey developed and some people chose to believe in, similar to the idea of numismatic collector coins. (People earlier last year were saying it is an attack on fungibility and making other irrational arguments, none of which were true if you applied the slightest logic to it.) It is not false nor scam, it is what some choose to believe. Some people are collectors, they do what seems to be weird, like this. Some large mining pools, like F2pool iirc, already engage in "ordinal theory", since there is a market for "rare sats" and so on. It cannot be stopped, and anyone can make any proposal, then it's up to the market if it cares or not.
I don't pretend to be an expert or understand any of this deeply btw, since I don't do it myself, but it is not a "scam" to buy a jpeg, stupid maybe depending what you value, but not a scam, unless the buyer is being misrepresented about what they are buying. If the buyer knows what it is, then it's not a scam, there is no fraud, they own the private key to the jpeg asset and so claim ownership, and then can and do engage in market buy/sell transactions with others who care about such stuff.
People are gambling, like they gamble with lottery tickets/casinos/penny stock trading/leveraged trading/etc. Gambling is not scamming. I know it's popular to call anything and everything a scam, but scam only comes into play if fraud is involved. If the buyer is aware of the situation, it cannot be a scam. And, as I already said, 'scam or not' is irrelevant to how the Bitcoin protocol, which is neutral, functions. This is not a centralized system. This is a decentralized system. You should think about what that means, instead of trying to force your morality onto a neutral value-transfer protocol like Bitcoin, in which value is subjectively determined (just like Bitcoin itself is subjectively valuable by some, and not by others who claim it is virtual nothingness). It does not make Bitcoin look like a scam, any more than people using Bitcoin to actually scam people (like with Plus Token or whatever that was called, and the other scams done over the years across the world using Bitcoin) made Bitcoin look like a scam. That is to say, I guess it's subjectively determined again. Some will not be interested in a decentralized permissionless system (with everything it entails -- they'll go to centralized fiat land), while others will respect the unique value offered by a decentralized system. You can only control how you yourself use Bitcoin, NOT how others use Bitcoin. You need to learn to remove your ego from Bitcoin. Bitcoin is not about you. People with big egos in Bitcoin's history tended to decide they knew better than Bitcoin, and tragedies ensued from that fatal error. This situation is not the first time it is starting to happen, and it won't be the last time. |
|
eragmus, there are ALREADY out of band Txs happening with ViaBtc.... See their latest block with 20 to 30 sat/vByte Txs: https://mempool.space/block/00000000000000000001b26d226a7993950d14bec4acce2d85eeb9974a63d9bf It seems to me that there are 2 camps here.. Those that think the standard Txs (including IsDust() ) should be defined for the benefit of the monetary network as a whole.... and then those, who think that these standard Txs should be defined by miners, pools on an individual basis. GetDustThreashold() includes the following comment: "If you'd pay more in fees than the value of the output to spend something, then we consider it dust." These standard Tx policies are obviously GOOD for the efficiency of the monetary network, and dust obviously shouldn't be hardcoded at 3 sat/vByte if the network never again drops below 20~40 sat/vByte. The integrity of the network and the real worth to miners is not short-term fees, but long-term growth and adoption of the MONETARY network itself. "Permisionless file storage" and dusty tokens that price out monetary Txs do NOT make a good combatant to the central banks, which IS the purpose of Bitcoin.. as evidenced in the Genesis Block itself. Nowhere did Satoshi Nakamoto mention the right to "trustlessly inscribe cartoons", but he definitely mentioned that Bitcoiners would want to keep the network slim, efficient, and focused. I truly hope that this goal is not lost on others, miners and core devs included. Most people know that to truly understand Bitcoin itself, you need to study cryptography, economics, programming, etc. This specific issue definitely needs some study in history and even language (defining things like "Bitcoin" itself, "standard Tx", "dust", etc. To throw all this out because it makes miners happy in the short-term is... well, short-sighted to say the least, while a large portion of Bitcoiners would say it's sacrilegious. To take something as sacred as freedom money, a tool to exit the fiat system, and then boast about fiat gains, is completely losing sight of the mission. |
|
This has now become a complete noise discussion. |
|
your longer paragraph has only proven my point further, until I see calm and collected responses to my original counterarguments to Pieter's false claims about the current attack on the Bitcoin network, I refuse to sift through straw man arguments formulated by someone who talks like Craig Wright and respond to each of them individually. As you can see someone else has already pointed out your base fallacy about out of band txs. |
maybe then contribute factual responses instead of ones based in pure speculation, ideology, and ignorance of publicly available facts. |
Read my arguments more carefully? Nowhere did I deny out of band txs are already happening. I said they will only get worse, if filtering is used as a policy response. And I said out of band txs can be logically reduced, if relay policies are aligned with consensus policies, instead of being out of sync and thus creating a reason for out of band txs.
Bitcoin works on economic incentives, not altruism. This is a core principle that needs to be internalized. And fees are exactly how bitcoin's security model is designed, fees and price of bitcoin. But price of bitcoin can't be controlled, and can be impacted by events out of our control, like macroeconomic climate and other global situations. Only fees are under our control, in terms of generating use cases that pay significant fees to offset the exponentially-declining subsidy paid by Bitcoin's inflation. The integrity of the network longterm revolves around tx fees. And fees matter because miners get paid by fees, longterm, to secure the network, as the subsidy becomes too nominal to matter. I've also stated several times in this thread (and surely others have too?), and it should be obvious if you think about it a little, that pricing out of lower-value normal txs is not a real concern, if using layer 2 networks like LN (and, in response to high fees, we recently got an easy to use wallet, Aqua, for sidechains like Liquid) to amortize cost of layer 1 tx fee. Actually if you send LN tx directly from LN-compatible exchange to a wallet, or Liquid bitcoin from exchange to wallet, like with Aqua, and then pay with only LN or Liquid, then you completely escape the layer 1 fee. -- And to focus efforts on actually useful efforts like scaling bitcoin via improving efficiency of layer 2 networks like LN and ARK, via CTV or other covenant proposals. This is getting so repetitive. It's like people don't care to actually read the prior discussion and understand it, before repeating the same old arguments over and over and over... |
This conversation seems noise only to those who don't want to hear the arguments of the folks who want to put better spam filters in place. For everyone else, there's tons of reasoning to help understand the issue better and hopefully get the point across THAT UPDATING SPAM FILTERS IS NEED OF THE HOUR and core cannot run away from it. |
If they are already happening it literally does not matter if they get any worse, your arguments are incredibly weak and you have shown that you do not understand the basic situation and or are maliciously ignorant. |
is not just some magical phrase you can throw around and make your assertions true. the incentives for full node runners are becoming smaller and smaller every single day. this demonstrably hurts decentralization of bitcoin. you people would care about that if you actually cared about the state of the mempool, but instead you are concern trolling that setting a filter to EVENLY DISTRIBUTE COST for all transactions will kill the mempool. Your fallacious arguments are tiring. |
It is funny how you say Bitcoin isn't about you however you think you can tell me what I can and cannot find to be a concern. Your hypocrisy is plenty evident. |
It's true, and it's not my problem if you don't understand how Bitcoin works, or refuse to accept it. As for node runners, as usual, this was addressed already in this thread, if you bothered to read it and understand the prior discussion, instead of spamming the thread. Or you could think for yourself, and actually figure out the answer? -- Which is that full node runners' storage is not affected worse by this situation vs. what would happen if the blocks were full of "normal" txs. And consensus already agreed to the current block size limits during the segwit fork, so the growth limits were agreed to and is bounded, and it was understood that growth rates are not sufficiently problematic for full nodes (and this was the case in 2017 or when segwit was implemented, while now it's 2024, 6 years later, with improved technology and even less concern).
What I said applies to the one changing Bitcoin. That would be you.
Plenty of people use it and have mostly no problems. And it is only 1 option I gave. You can support efforts, as I already said, to improve LN functionality, like with CTV or other covenant proposals. And you can use Liquid sidechain, via the Aqua wallet. But you are not entitled, as bcashers also felt entitled, to use Bitcoin layer 1 for lower-value txs despite being unable to afford the layer 1 tx fee. Bitcoin doesn't scale via layer 1, it scales via other layers. We established this during block size controversy, and if you don't agree with this decision, consider using bcash instead?
Using bitcoin in a way you disagree with, and paying for the privilege with competitive tx fees, is not an "attack". What's an attack is feeling entitled to pay low fees on layer 1 to make txs on Bitcoin, and trying to bully developers to cater to your false understanding of Bitcoin.
If that's what you think about my arguments, and those of others here who basically make similar or same arguments, you have a few options (since Bitcoin is not a democracy & since Core obviously lacks rough consensus to be able to implement the proposed change):
Good luck. |
|
It is highly troubling to see this discord between people involved in bitcoin. As someone who recently joined the community, I find it unsettling. My stance is that monetary proposition of bitcoin is the one and only thing that core team must be focused on, but now I see that goal is lost, intentionally or not. Everyone like to spout 'decentralization', but how is pushing people to sidechains not centralization is beyond me. I find argument that everything will be solved with L2/L3, especially coming from core devs,... Wrong for the lack of better word. Core team imho should be focusing on fixing existing issues with L1 and one of those problems is staring us in the face. Sorry for being blunt. |
Bitcoin is a decentralized system, so discord is natural. The guy I've been talking with is particularly nasty, but this is fortunately not the norm in the discussion thread, if you read the rest of it.
I know people think of it idealistically this way, as did I for a long time (actually until Jan of 2023, when I thought about it more deeply), but it is not realistic to force people to use their bitcoin in one narrow manner. Bitcoin is a permissionless network. People will inherently use it for whatever they personally find useful.
It is not a black/white situation either, where it's either 100% monetary use or 0% monetary use. It will be based on competitive tx fee rates determining the proportion of uses. Basically, the market will decide the price of miners' precious layer 1 block space (fee rate), and what proportion of use cases by the buyers.
Decentralization comes in degrees.
There are tradeoffs across different layers. This is how blockchain works to remain decentralized. Blockchain is not magic.
Simple fact of the matter is it can't be fixed (without some type of fork), and the reasons why have been explained ad nauseam in this thread. And a fork would obviously be a very big deal; first, it would need to be figured out (one idea is implementing Confidential Transactions on Bitcoin, just as it is on the Liquid sidechain), and then it would need to gain rough consensus that pros sufficiently > cons. |
|
I hope the following information helps in adding clarity to the thought process of folks who advocate otherwise: "Satoshi made only 1 mistake, which I believe is the root of the confusion among some Bitcoiners who defend spam. He used the same name bitcoin - to define two different elements: the asset, and the network. Although they are interdependent, they possess very distinct properties. The network is decentralized, permission-less, and resistant to censorship - not the asset. The asset is divisible, portable, scarce, and durable - not the network. Crucially, to benefit from the asset's properties, one must have access to the network, and vice versa. For instance, imagine holding a certain amount of BTC in self-custody, but facing prohibitively high fees that prevent you from moving it, essentially blocking access to the network. In this scenario, the Bitcoin loses its portability and divisibility. Conversely, consider running 100 nodes, but for some reason being unable to acquire the asset. Those who justify spam under the pretext of "Bitcoin is for enemies" fail to grasp this crucial distinction between the asset and the network. Bitcoin - the asset - is for adversaries. However, Bitcoin the network must be safeguarded at all costs, or we risk losing all the properties that define Bitcoin." Credit for this information goes to @matteopelleg My argument would be that Bitcoin - the network - needs to be protected from spam RIGHT NOW and if corporate sponsored devs at core with merge rights are incompetent in understanding the situation or to put the solution in place, they should step down and let other non corporate funded, community oriented, technically more skilled devs take control of the situation and make efforts to fix the spam issue. Core does not belong to devs sponsored by one or two companies. It's a shared code and we all need to take responsibility of fixing the issue of spam. Thank you. |
|
This is a summary of the arguments on the PRs, mailing list posts, and some tweets. ACKs by reasonIf you feel I have misrepresented something you said, feel free to let me know. "Stop inscriptions, which are spam"These types of transactions are used for ordinals, NFTs, data-carrying, or some use case that is not
"Inscriptions and embedded data harm the network"These types of transactions are costly for node operators and are harming the network in some way.
"People want this"Clearly there is user desire and a specific use case, so Bitcoin Core should offer this option. The
"This just fixes datacarriersize to work as intended"We limit data-carrying in OP_RETURNs. This should be applied to all types of data-carrying. This is
NACKs by reasonHere is a summary of the arguments against this PR. "This will not prevent inscriptions"This will not stop inscriptions. It is unlikely (because it's incentive-incompatible) that miners
"We cannot write code to detect all data-carrying"In general, we cannot stop data-carrying transactions. Inscriptions exist amongst numerous ways to
"This change is potentially harmful"This PR, which changes the default mempool policy, is potentially harmful to the individual node
Other points against the PRGenerally, using mempool policy to discourage usage is now ineffective, even though it has been used
ReviewConcept NACK. Trying to keep the points that have already been said short:
|
|
@glozow You missed the most important, censorship |
|
Concept NACK Purpose of
|
How Sarcasm Works: Maxi: "Did you eat another doughnut?" I dont think youll be able to reliably cling to a video of BSVers trolling you as evidence of the total illegitimacy of ordinals if irony sarcasm and spite exist, and I checked, they do exist. It makes sense after the reaction to ordinals that people might overstate themselves in the way designed to bother you as they have here. "We're here to ruin bitcoin" is not a sincere statement, it's meant to mock your reactions which seems beyond your understanding or maybe just your honesty. |
Except that most new noderunners are ordinals indexers and inscribers. Ordinals are here to stay, fork off or accept it. |
|
Seems pointless to argue the politics of the change when CI doesn't even pass: There are two different aspects of mempool policy: what you can configure the software to enforce, and the defaults. From that view, this PR is flawed in two ways:
So that's an Approach NACK for me. I believe core's strategy for PRs that add disabled-by-default mempool/relay rules is that it's fine for add config options if people want to set their own rules for their own node, even if that will result in them diverging from the network at large, provided the code supporting the option is reasonably small/self-contained/maintainable, and there's at least some demand for the option. On that basis I expect I'd be happy to invert that nack if the PR were modified to introduce an independent option for blocking txs with redundant script code that defaulted to off. (And also fixed the bugs that are resulting in CI failure, obviously) (Note that Knots has also recently introduced (see 1 and 2) a default limit of 1650 bytes for scripts, which eg limits CHECKSIGADD-based multisig to about k/50; rather than up to about 1000/4000. I'm not sure there's actually any demand for that change in additional to filtering inscriptions, but if there is, presumably it would also be acceptable as a default-off policy option in core) I expect I'd remain a nack on changing the default unless there was clear evidence that a majority of hashrate was either supportive-of or indifferent-to the change, eg a majority of blocks were already excluding these transactions. (ie, I'd accept that as resolving most of the concerns expressed in sipa's comment) Personally I think changes here (whether adding an option or changing the default) is unlikely to have any effect outside of generating tweets/articles/podcast episodes, and that in the unlikely event that it did have any effect, that would only be for witness-embedded data to use a different pattern. (ie, basically, what Murch said) |
The incentive would be lower fees as they don't need to compete with people wanting to make legitimate btc txs |
where is the evidence that the majority of inscription fees are being motivated by network harm as opposed to immutable record of information? |
|
It's abundantly clear that this PR is controversial and, in its current state, has no hope of reaching a conclusion that is acceptable to everyone. At this point in time, I see no reason to leave this open and to continue to send notifications for the constant back-and-forth stalemate discussion. |
Updates
-datacarriersizeto be effective with newer datacarrying styles.