The discount is designed to reduce UTXO bloat primarily, witness spam data would not make it into the UTXO set. The discount brings the fee of a transaction more in line with the actual costs to the network for the transaction. A miner spamming the network with 4MB witness blocks would have very little impact on the UTXO size compared with 1MB non-witness blocks. UTXO size is a bigger issue than blockchain size since full nodes can't prune the UTXO set.
The discount of 75% for the SegWit softfork doesn't really have any effect on future hard forks as it can always be adjusted as needed later on as part of a HF. On Tue, May 9, 2017 at 8:49 AM, Sergio Demian Lerner via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > This [1] article says the current discount prevents witness spam. Witness > spam is free space in the witness part of the block that can be filled by > miners to create bigger blocks with almost no cost for the benefit a cluster > of miners with low latency, increasing centralization. > > The 75% discount does not prevent it, but on the contrary leaves a lot of > extra witness space for spam. > > If the maximum block weight is set to 2.7M, each byte of non-witness block > costs 1.7, and each byte of witness costs 1, then a normal filled block > would be 2.7M bytes (1.7+1), and there will be no need to create ever a 4 > Mbyte block. The worst case would be the average case, and the transaction > rate would be the maximum possible. > > The current 75% discount can only achieve more transactions per second if > the type of transactions change. Therefore the current 75% discount only > makes the block size worst case worse (4 Mbytes when it should be 2.7 > Mbytes). > > 80% of all inputs/outputs are P2PKH. The only way to make use of the extra > witness > space If most P2PKH transactions are replaced by multisigs (typically for > LN). > > So it seems the 75% discount has been chosen with the idea that in the > future the current transaction pattern will shift towards multisigs. This is > not a bad idea, as it's the only direction Bitcoin can scale without a HF. > But it's a bad idea if we end up doing, for example, a 2X blocksize increase > HF in the future. In that case it's much better to use a 50% witness > discount, and do not make scaling risky by making the worse case block size > 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes. > > I've uploaded the code here: > https://github.com/SergioDemianLerner/SegwitStats > > [1] > https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e. > > > On Mon, May 8, 2017 at 8:47 PM, Alphonse Pace via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> Sergio, >> >> I'm not sure what the data you present has to do with the discount. A 75% >> discount prevents witness spam precisely because it is 75%, nothing more. >> The current usage simply gives a guideline on how much capacity is gained >> through a particular discount. With the data you show, it would imply that >> those blocks, with SegWit used where possible, would result in blocks of >> ~1.8MB. >> >> >> >> On Mon, May 8, 2017 at 5:42 PM, Sergio Demian Lerner via bitcoin-dev >> <bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >>> I have processed 1000 blocks starting from Block #461653. >>> >>> I computed several metrics, including the supposed size of witness data >>> and non-witness data (onchain), assuming all P2SH inputs/outputs are >>> converted to P2PWSH and all P2PKH inputs/outputs are converted to P2WPKH. >>> >>> This takes into account that other types of transactions will not be >>> modified by Segwit (e.g. OP_RETURN outputs, or P2PK). This analysis doesn't >>> take into account that LN transactions may affect the current state, >>> increasing the segwit/nosegwit ratio. >>> >>> Among a lot of information, I've got the following real world results... >>> >>> acMainChainSpace =352608924 >>> acSegwitSpace =599400403 >>> Ratio segwit/nosegwit=1.6999 >>> >>> This implies that the 75% that discount is not the best option to prevent >>> witness spam in a block of 4 MB, as stated in >>> https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e. >>> >>> The non-witness data weight factor should not be 4 but 2.35. The closest >>> integer value is 2, which leads to a 50% witness discount. >>> >>> The Bitcoinj source code is available for anyone to review. I encourage >>> anyone to re-compute this with another utility to cross-check. Maybe Antoine >>> Le Calvez (p2sh.info) would like to double-check. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
