Post by Sergio Demian Lerner via bitcoin-dev

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.

https://github.com/SergioDemianLerner/SegwitStats

[1] https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e

<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

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

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

<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

<http://p2sh.info>) would like to double-check.

_______________________________________________

bitcoin-dev mailing list

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>

_______________________________________________

bitcoin-dev mailing list

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>

_______________________________________________

bitcoin-dev mailing list

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

This [1] article says the current discount prevents witness spam.Witness spam is free space in the witness part of the block that can befilled by miners to create bigger blocks with almost no cost for thebenefit a cluster of miners with low latency, increasing centralization.The 75% discount does not prevent it, but on the contrary leaves a lotof extra witness space for spam.If the maximum block weight is set to 2.7M, each byte of non-witnessblock costs 1.7, and each byte of witness costs 1, then a normal filledblock would be 2.7M bytes (1.7+1), and there will be no need to createever a 4 Mbyte block. The worst case would be the average case, and thetransaction rate would be the maximum possible.The current 75% discount can only achieve more transactions per secondif the type of transactions change. Therefore the current 75% discountonly makes the block size worst case worse (4 Mbytes when it should be2.7 Mbytes).80% of all inputs/outputs are P2PKH. The only way to make use of theextra witnessspace If most P2PKH transactions are replaced by multisigs (typicallyfor LN).So it seems the 75% discount has been chosen with the idea that in thefuture the current transaction pattern will shift towards multisigs.This is not a bad idea, as it's the only direction Bitcoin can scalewithout a HF.But it's a bad idea if we end up doing, for example, a 2X blocksizeincrease 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 caseblock size 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes.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-devSergio,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 howmuch capacity is gained through a particular discount. With thedata you show, it would imply that those blocks, with SegWit usedwhere possible, would result in blocks of ~1.8MB.On Mon, May 8, 2017 at 5:42 PM, Sergio Demian Lerner via bitcoin-devI have processed 1000 blocks starting from Block #461653.I computed several metrics, including the supposed size ofwitness data and non-witness data (onchain), assuming all P2SHinputs/outputs are converted to P2PWSH and all P2PKHinputs/outputs are converted to P2WPKH.This takes into account that other types of transactions willnot be modified by Segwit (e.g. OP_RETURN outputs, or P2PK).This analysis doesn't take into account that LN transactions mayaffect the current state, increasing the segwit/nosegwit ratio.Among a lot of information, I've got the following real world results...acMainChainSpace =352608924acSegwitSpace =599400403Ratio segwit/nosegwit=1.6999This implies that the 75% that discount is not the best optionto prevent witness spam in a block of 4 MB, as stated inhttps://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. Theclosest integer value is 2, which leads to a 50% witness discount.The Bitcoinj source code is available for anyone to review. Iencourage anyone to re-compute this with another utility tocross-check. Maybe Antoine Le Calvez (p2sh.info ) would like to double-check._______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

I'm not sure who wrote segwit.org, but I wouldn't take it asauthoritative reasoning why we must do X over Y.You seem to be claiming that there is not cost for a miner to fill"extra witness space", but this is very untrue - in order to do so theymust forgo fees on other transactions. Your analysis on worst-case vsnormal-case blocks also seems flawed - there is a single limit, and nota separate, secondary, witness limit.You suggested "If the maximum block weight is set to 2.7M, each byte ofnon-witness block costs 1.7", but these numbers dont work out - settingthe discount to 1.7 gets you a maximum block size of 1.7MB (in a softfork), not 2.7MB. If you set the max block weight to 2.7 with a 1.7xdiscount, you have a hard fork. If you set the discount to 2.7x with a2.7 weight limit, you dont get 2.7MB average-sized blocks, but smaller,and still have the potential for padding blocks with pure-witness datato create larger blocks.Additionally, note that by padding blocks with larger witness data youlose some of the CPU cost to validate as you no longer have as manyinputs (which have a maximal validation cost).Further, I'm not sure why you're arguing for a given witness discount onthe basis of a future hardfork - it seems highly unlikely the communityis in a position to pull something like that off, and even if it were,why set the witness discount with that assumption? If there were to be ahardfork, we should probably tweak a bunch of parameters (see, eg, mypost from February of last year athttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012403.html).Maybe you could clarify your proposal a bit here, because the way I readit you seem to have misunderstood SegWit's discount system.