Some real-world results about the current Segwit Discount

Summary:

In this conversation, Sergio Demian Lerner via bitcoin-dev argues that the current discount system of 75% for SegWit is not the best way to prevent witness spam in a block of 4 MB, as it leaves extra witness space for spam. He suggests that the non-witness data weight factor should not be 4 but 2.35 and a 50% witness discount would be better. However, Alphonse Pace via bitcoin-dev disagrees with Sergio’s analysis and claims that a 75% discount prevents witness spam precisely because it is 75%, nothing more. Alphonse also states that with the current usage, blocks with SegWit used where possible would result in blocks of ~1.8MB. Sergio further elaborates on his point by stating that setting the discount to 1.7 gets you a maximum block size of 1.7MB (in a soft fork), not 2.7MB. If you set the max block weight to 2.7 with a 1.7x discount, you have a hard fork. If you set the discount to 2.7x with a 2.7 weight limit, you don't get 2.7MB average-sized blocks, but smaller, and still have the potential for padding blocks with pure-witness data to create larger blocks. Additionally, he points out that by padding blocks with larger witness data, some of the CPU cost to validate is lost, as there are not as many inputs which have a maximal validation cost. Moreover, Sergio questions why someone would argue for a given witness discount on the basis of a future hardfork, as it seems highly unlikely the community is in a position to pull something like that off. Even if it were, why set the witness discount with that assumption? If there were to be a hardfork, we should probably tweak a bunch of parameters. He also notes that the current 75% discount can only achieve more transactions per second if the type of transactions change. Sergio believes it is better to use a 50% witness discount and not make scaling risky by making the worst case block size 8 Mbytes when it could have been 2*2.7=5.4 Mbytes. Sergio’s code is available on Github for anyone to review, and he encourages others to re-compute this with another utility to cross-check. Antoine Le Calvez (p2sh.info) could also double-check.

Updated on: 2023-05-20T02:13:52.193871+00:00