Fraud and misrepresentation in the sphere of cryptocurrency? Say it isn't so! > This vulnerability may partly be due to the discount for witness vBytes in Seg

Fraud and misrepresentation in the sphere of cryptocurrency? Say it isn't so! > This vulnerability may partly be due to the discount for witness vBytes in SegWit, That's erroneous thinking resulting from a false and confused description that uses the word "discount". An attacker's objective is to deny access to capacity to other participants by outbidding them for available capacity. It doesn't matter what units the capacity is in or how its measured, all that matters is how much they're willing to spend each and every block to outbid the other participants. The fact that prunable witness data doesn't use up as much of the capacity limit as other data is completely irrelevant to the attackers power. If, on the other hand, the attack were "we're using up the users disk space and it's cheaper to do it with transactions that have way more than typical witness bytes" that would be another story. But since the witness data is completely prunable it's not a suitable attack on storage to begin with, which is why it counts less against the capacity limit. > relaxed witness size restrictions in the P2TR (Pay to Taproot) transactions scheme I think that's also confused. Beyond the overall limit on the block there are no consensus limits. There have been standardness limits which limit what nodes are willing to relay and mine out of the box, but they're not imposed in consensus. My understanding is that recent ordinals floods have involved transactions over the standardness size limits, so at least those are being added with the cooperation of miners (tens of millions of dollars in fees apparently buys a lot of cooperation) so standardness rules are irrelevant, only consensus rules matter. So I think it's doubtful that standardness rules would help, and given the years of relentless harassment of bitcoin developers over other standardness rules like the 40 byte op_return limit I doubt anyone would bother trying even if they thought it might help. I think people fall into this kind of misunderstand because they fail to think through where transaction fees come from-- they're not specified by the protocol. They're a result of market forces acting between demand and capacity limits so there isn't a way to use up capacity at lower marginal cost since the cost arises directly from capacity. Or to be more clear: no way at issue here. I believe the authors of the taproot specs intentionally designed it to not need any other limits than the overall block weight specifically because having additional limits creates an avenue for attackers to use capacity at lower cost. An example is the old 20,000 sigops limitation in pre-segwit transactions: An attacker could create small transactions that burned up the separate sigops limit without using much weight, and since the sigops limit is normally not even close to limiting the miners txn selection would irrationally accept attack transactions that displaced more honest transactions than should have been implied by their fees. I believe that attack vector is closed by the mining algorithm using an ad-hoc solution of the mining transaction scaling a transactions share of the sigops total to the weight limit and using it as the transaction weight in selection. This, in theory, results in an incentive incompatible transaction selection (so a miner following it would eventually be bankrupt against miners that didn't) but thats a non-issue in practice because only attack transactions trigger the maximum operation and when the attack doesn't work there is no incentive to create the attack transactions. But that kind of ad-hoc fix was only really viable because the sigops limit was high enough to never matter for real transactions. Perhaps more relevantly, on the subject of attacking through denial of service-- the attacker is free to structure their transactions however they like... they only need to burn up capacity. In any case, outbidding isn't normally an attack that creates much concern because it's phenomenally expensive and the expense is ongoing: the to block the next best transaction X the attacker has to spend more that it in fees in each block its blocked from... while the defender only needs to get their transaction in once. The fact that adding random limits can't actually stop a spam attack (at most it just forces the attacker to shape their transactions in a less distinguishable way) was the first thing people pointed out on the mailing list when this latest generation of spam attacks was brought up.