> Maximum transaction size is kept, to maximize compatibility with current > software and prevent algorithmic and data size DoS's.
IIRC, it is actually increased by ~81 bytes, and doesn't count witness data if on Segwit transactions (so in effect, nearly 4 MB transactions are possible). This probably doesn't make the hashing problem worse, however it should be made clear in the BIP. > Assuming the current transaction pattern is replicated in a 2 MB > plain-sized block that is 100% filled with transactions, then the > witness-serialized block would occupy 3.6 MB [1]. This is considered safe > by many users, companies, miners and academics [2]. Citations do not support the claim. > The plain block size is defined as the serialized block size without > witness programs. This is deceptive and meaningless. There is no reason to *ever* refer to the size of the block serialised without witness programs. It is not a meaningful number. > Deploy a modified BIP91 to activate Segwit. The only modification is that > the signal "segsignal" is replaced by "segwit2x". What is modified here? "segsignal" does not appear in the BIP 91 protocol at all... > If segwit2x (BIP91 signal) activates at block N, then block N+12960 > activates a new plain block size limit of 2 MB (2,000,000 bytes). In this > case, at block N+12960 a hard-fork occurs. A "plain block size limit" of 2 MB would be a no-op. It would have literally no effect whatsoever on the network rules. Furthermore, this does not match what btc1/Segwit2x currently implements at all. The actual implementation is: If Segwit (via deployment method) activates at block N, then block N+12960 activates a new weight limit of 8M (which corresponds to a size of up to 8,000,000 bytes). > Any transaction with a non-witness serialized size exceeding 1,000,000 is > invalid. What is the rationale for excluding witness data from this measurement? > In the short term, an increase is needed to continue to facilitate network > growth, and buy time... Actual network growth does not reflect a pattern that supports this claim. > This reduces the fee pressure on users and companies creating on-chain > transactions, matching market expectations and preventing further market > disruption. Larger block sizes is not likely to have a meaningful impact on fee pressure. Any expectations that do not match the reality are merely misguided, and should not be a basis for changing Bitcoin. Luke _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev