In the long term, I believe/hope that fee effects matter. There will likely be times of mempool congestion with feerate spikes, and future businesses and projects will make decisions that are conscious of fee impact.
But for P2TRv2, which IMO ought to prioritize adoption by the long tail, and ideally soon to give a long window for that adoption. For that long tail, I expect the bottleneck to be software/wallet/custodian support by existing providers, and with high probability in the relatively short term, I don’t think fee arguments will affect them much.
Your point here is about easy of implementation by developers. I agree in principle, except for a minor concern about “we’ll look into this later” if the change seems complex, which I commented on earlier:
The part you’re responding to above is about timing consensus changes, not wallet implementation however. In short, I think adding CISA to the P2TRv2 bundle will increase the time it takes for P2TRv2 to become available, and that will likely reduce adoption before Q-day by the long tail more than fee incentives will increase it. I’m sympathetic to the fact that CISA inherently needs a new output type, which makes it a natural fit for combining, but I still think it distracts from P2TRv2’s goal. If it’s not bundled with P2TRv2, it will need yet another output type, be bundled with P2MR, or not done at all.
Post-Q-day, if hash-based PQC is adopted, I think the need for a different witness costing rule (and thus larger (pre-aggregated) serialized block sizes) is almost an inevitability, regardless of whether block-wide aggregation is involved. The actual formula will of course be greatly influenced by the details, ideally accounting for all facets of resource impact (bandwidth, storage, validation, relay). Historically, serialized size and CPU validation costs were roughly proportional, justifying a largely size-based formula. But with cryptography that has a different CPU/size ratio, it seems inappropriate to only account for size. That doesn’t need to mean that PQC sigs need to be competitive with ECC ones, but some capacity (in bytes) increase seems warranted if it doesn’t come with a proportional CPU increase:
IMO, we will need a new witness extension if Q-day happens, and it seems reasonable to aim to have the technology ready for that before Q-day. A way of doing that in a structured way that improves some of segwit’s pain points is described in the witness styles thread (but that’s just one option), and it seems reasonable (but not necessary) to combine that with the later-stage P2MR construction, as it can give a fee structure even for ECC that matches the incentive structure of P2TR, or even exceeding it by matching (half-agg) CISA.
Sure, someone has to store the full block data, but not everyone. Nodes and their operators themselves don’t need full data (pruning doesn’t reduce security or functionality), and if pressure on non-pruned nodes by IBD’ing new nodes grows too big, block storage could be sharded. Using FEC techniques it is possible to for example let every node store 20% of every block, in such a way that any combination of 5 nodes together can let you reconstruct everything.
Of all the potential ways additional block data impacts network properties, I consider archive node storage size the least concerning. It’s simply never even been close to a problem, and disks have been growing faster than the chain has for a long time already, and furthermore technological solutions exist that can push it further away even.
Yes, it does, since 2013 (inside blocks, not for individually relayed transactions).
IBD is for most users not bandwidth constrained (but we’re getting closer in the upcoming 32.0 release thanks to a number of performance improvements), and I don’t think pruning is an issue.
Bandwidth and CPU cost for validation at the tip however is much more concerning to me, as it’s what allows the network to stay in sync, both between miners, and between nodes. But I also don’t think we need to stick to limits set 9 years ago with the adoption of segwit.
Aggregation, even at the block level, won’t remove the need for bandwidth for transaction relay prior to block building. It removes one facet of the impact of increased sizes (the ability for weak nodes to keep up with auditing the chain). The ability for nodes to participate in providing the market for block space (i.e., the mempool), which is also an important facet of decentralization (allows for permissionless entry into the mining market, without centralized block-building services), isn’t really affected by aggregation. Improving one may justify an increase in the resource limit on pre-aggregated block data, but I don’t think it’s reasonable to disregard that limit entirely and only look at aggregated size.
My stance is that resource limits in blocks should, for the time being, be set in terms of the CPU usage and pre-aggregated bandwidth imposed on validation nodes. Some increases in bandwidth are warranted, both because network and processing capacities have increased the past decade, and because with hash-based signatures, the CPU cost of validation doesn’t have the same per-byte cost anymore. Aggregation is something that can be explored independently, and when it’s ready, maybe that’s a justification for future resource costing.
I agree, it shouldn’t. I think in general the “near-term P2TRv2” idea shouldn’t include any such thing in general.
I don’t really see what that has to do with the signature scheme. To give a different weight to block data (below 1 WU/byte) you need a new witness extension, which is a combination of P2P-level and consensus-level changes, reaching beyond script or signature logic.
Yes…
Policy won’t suffice here. The reason for having resource limits is to prevent miners from creating blocks that have a too large impact, on the network and on each other.