{"type":"rich","version":"1.0","author_name":"npub1fvuxqdqg7klqqgy3yy8gdxjv4phu92sll5y8zqm2qe5qdrhxymhqf3vq7f","author_url":"https://nostr.ae/npub1fvuxqdqg7klqqgy3yy8gdxjv4phu92sll5y8zqm2qe5qdrhxymhqf3vq7f","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-05-09\n📝 Original message:This [1] article says the current discount prevents witness spam. Witness\nspam is free space in the witness part of the block that can be filled by\nminers to create bigger blocks with almost no cost for the benefit a\ncluster of miners with low latency, increasing centralization.\n\nThe 75% discount does not prevent it, but on the contrary leaves a lot of\nextra witness space for spam.\n\nIf the maximum block weight is set to 2.7M, each byte of non-witness block\ncosts 1.7, and each byte of witness costs 1, then a normal filled block\nwould be 2.7M bytes (1.7+1), and there will be no need to create ever a 4\nMbyte block. The worst case would be the average case, and the transaction\nrate would be the maximum possible.\n\nThe current 75% discount can only achieve more transactions per second if\nthe type of transactions change. Therefore the current 75% discount only\nmakes the block size worst case worse (4 Mbytes when it should be 2.7\nMbytes).\n\n80% of all inputs/outputs are P2PKH. The only way to make use of the extra\nwitness\nspace If most P2PKH transactions are replaced by multisigs (typically for\nLN).\n\nSo it seems the 75% discount has been chosen with the idea that in the\nfuture the current transaction pattern will shift towards multisigs. This\nis not a bad idea, as it's the only direction Bitcoin can scale without a\nHF.\nBut it's a bad idea if we end up doing, for example, a 2X blocksize\nincrease HF in the future. In that case it's much better to use a 50%\nwitness discount, and do not make scaling risky by making the worse case\nblock size 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes.\n\nI've uploaded the code here:\nhttps://github.com/SergioDemianLerner/SegwitStats\n\n [1] https://segwit.org/why-a-discount-factor-of-4-why-not-\n2-or-8-bbcebe91721e.\n\n\nOn Mon, May 8, 2017 at 8:47 PM, Alphonse Pace via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Sergio,\n\u003e\n\u003e I'm not sure what the data you present has to do with the discount.  A 75%\n\u003e discount prevents witness spam precisely because it is 75%, nothing more.\n\u003e The current usage simply gives a guideline on how much capacity is gained\n\u003e through a particular discount.  With the data you show, it would imply that\n\u003e those blocks, with SegWit used where possible, would result in blocks of\n\u003e ~1.8MB.\n\u003e\n\u003e\n\u003e\n\u003e On Mon, May 8, 2017 at 5:42 PM, Sergio Demian Lerner via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e I have processed 1000 blocks starting from Block #461653.\n\u003e\u003e\n\u003e\u003e I computed several metrics, including the supposed size of witness data\n\u003e\u003e and non-witness data (onchain), assuming all P2SH inputs/outputs are\n\u003e\u003e converted to P2PWSH and all P2PKH inputs/outputs are converted to P2WPKH.\n\u003e\u003e\n\u003e\u003e This takes into account that other types of transactions will not be\n\u003e\u003e modified by Segwit (e.g. OP_RETURN outputs, or P2PK). This analysis doesn't\n\u003e\u003e take into account that LN transactions may affect the current state,\n\u003e\u003e  increasing the segwit/nosegwit ratio.\n\u003e\u003e\n\u003e\u003e Among a lot of information, I've got the following real world results...\n\u003e\u003e\n\u003e\u003e acMainChainSpace =352608924\n\u003e\u003e acSegwitSpace =599400403\n\u003e\u003e Ratio segwit/nosegwit=1.6999\n\u003e\u003e\n\u003e\u003e This implies that the 75% that discount is not the best option to prevent\n\u003e\u003e witness spam in a block of 4 MB, as stated in\n\u003e\u003e https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e\n\u003e\u003e .\n\u003e\u003e\n\u003e\u003e The non-witness data weight factor should not be 4 but 2.35. The closest\n\u003e\u003e integer value is 2, which leads to a 50% witness discount.\n\u003e\u003e\n\u003e\u003e The Bitcoinj source code is available for anyone to review. I encourage\n\u003e\u003e anyone to re-compute this with another utility to cross-check. Maybe\n\u003e\u003e Antoine Le Calvez (p2sh.info) would like to double-check.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170509/38a4f95e/attachment.html\u003e"}