{"type":"rich","version":"1.0","author_name":"npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","author_url":"https://nostr.ae/npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-05-09\n📝 Original message:I'm not sure who wrote segwit.org, but I wouldn't take it as\nauthoritative reasoning why we must do X over Y.\n\nYou seem to be claiming that there is not cost for a miner to fill\n\"extra witness space\", but this is very untrue - in order to do so they\nmust forgo fees on other transactions. Your analysis on worst-case vs\nnormal-case blocks also seems flawed - there is a single limit, and not\na separate, secondary, witness limit.\n\nYou suggested \"If the maximum block weight is set to 2.7M, each byte of\nnon-witness block costs 1.7\", but these numbers dont work out - setting\nthe discount to 1.7 gets you a maximum block size of 1.7MB (in a soft\nfork), not 2.7MB. If you set the max block weight to 2.7 with a 1.7x\ndiscount, you have a hard fork. If you set the discount to 2.7x with a\n2.7 weight limit, you dont get 2.7MB average-sized blocks, but smaller,\nand still have the potential for padding blocks with pure-witness data\nto create larger blocks.\n\nAdditionally, note that by padding blocks with larger witness data you\nlose some of the CPU cost to validate as you no longer have as many\ninputs (which have a maximal validation cost).\n\nFurther, I'm not sure why you're arguing for a given witness discount on\nthe basis of a future hardfork - it seems highly unlikely the community\nis in a position to pull something like that off, and even if it were,\nwhy set the witness discount with that assumption? If there were to be a\nhardfork, we should probably tweak a bunch of parameters (see, eg, my\npost from February of last year at\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012403.html).\n\nMaybe you could clarify your proposal a bit here, because the way I read\nit you seem to have misunderstood SegWit's discount system.\n\nOn 05/09/17 13:49, Sergio Demian Lerner via bitcoin-dev wrote:\n\u003e This [1] article says the current discount prevents witness spam.\n\u003e Witness spam is free space in the witness part of the block that can be\n\u003e filled by miners to create bigger blocks with almost no cost for the\n\u003e benefit a cluster of miners with low latency, increasing centralization.\n\u003e \n\u003e The 75% discount does not prevent it, but on the contrary leaves a lot\n\u003e of extra witness space for spam.\n\u003e \n\u003e If the maximum block weight is set to 2.7M, each byte of non-witness\n\u003e block costs 1.7, and each byte of witness costs 1, then a normal filled\n\u003e block would be 2.7M bytes (1.7+1), and there will be no need to create\n\u003e ever a 4 Mbyte block. The worst case would be the average case, and the\n\u003e transaction rate would be the maximum possible.\n\u003e \n\u003e The current 75% discount can only achieve more transactions per second\n\u003e if the type of transactions change. Therefore the current 75% discount\n\u003e only makes the block size worst case worse (4 Mbytes when it should be\n\u003e 2.7 Mbytes).\n\u003e \n\u003e 80% of all inputs/outputs are P2PKH. The only way to make use of the\n\u003e extra witness \n\u003e space If most P2PKH transactions are replaced by multisigs (typically\n\u003e for LN).\n\u003e \n\u003e So it seems the 75% discount has been chosen with the idea that in the\n\u003e future the current transaction pattern will shift towards multisigs.\n\u003e This is not a bad idea, as it's the only direction Bitcoin can scale\n\u003e without a HF. \n\u003e But it's a bad idea if we end up doing, for example, a 2X blocksize\n\u003e increase HF in the future. In that case it's much better to use a 50%\n\u003e witness discount, and do not make scaling risky by making the worse case\n\u003e block size 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes.\n\u003e \n\u003e I've uploaded the code here:\n\u003e https://github.com/SergioDemianLerner/SegwitStats\n\u003e \n\u003e  [1] https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e\n\u003e \u003chttps://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e\u003e.\n\u003e \n\u003e \n\u003e On Mon, May 8, 2017 at 8:47 PM, Alphonse Pace via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e \n\u003e     Sergio,\n\u003e \n\u003e     I'm not sure what the data you present has to do with the discount. \n\u003e     A 75% discount prevents witness spam precisely because it is 75%,\n\u003e     nothing more.  The current usage simply gives a guideline on how\n\u003e     much capacity is gained through a particular discount.  With the\n\u003e     data you show, it would imply that those blocks, with SegWit used\n\u003e     where possible, would result in blocks of ~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\n\u003e     \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e     \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e \n\u003e         I have processed 1000 blocks starting from Block #461653.\n\u003e \n\u003e         I computed several metrics, including the supposed size of\n\u003e         witness data and non-witness data (onchain), assuming all P2SH\n\u003e         inputs/outputs are converted to P2PWSH and all P2PKH\n\u003e         inputs/outputs are converted to P2WPKH.\n\u003e \n\u003e         This takes into account that other types of transactions will\n\u003e         not be modified by Segwit (e.g. OP_RETURN outputs, or P2PK).\n\u003e         This analysis doesn't take into account that LN transactions may\n\u003e         affect the current state,  increasing the segwit/nosegwit ratio.\n\u003e \n\u003e         Among a lot of information, I've got the following real world\n\u003e         results...\n\u003e \n\u003e         acMainChainSpace =352608924\n\u003e         acSegwitSpace =599400403\n\u003e         Ratio segwit/nosegwit=1.6999\n\u003e \n\u003e         This implies that the 75% that discount is not the best option\n\u003e         to prevent witness spam in a block of 4 MB, as stated in\n\u003e         https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e\n\u003e         \u003chttps://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e\u003e.\n\u003e \n\u003e         The non-witness data weight factor should not be 4 but 2.35. The\n\u003e         closest integer value is 2, which leads to a 50% witness discount.\n\u003e \n\u003e         The Bitcoinj source code is available for anyone to review. I\n\u003e         encourage anyone to re-compute this with another utility to\n\u003e         cross-check. Maybe Antoine Le Calvez (p2sh.info\n\u003e         \u003chttp://p2sh.info\u003e) would like to double-check.\n\u003e \n\u003e \n\u003e \n\u003e \n\u003e \n\u003e \n\u003e         _______________________________________________\n\u003e         bitcoin-dev mailing list\n\u003e         bitcoin-dev at lists.linuxfoundation.org\n\u003e         \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e         https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e         \u003chttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\u003e\n\u003e \n\u003e \n\u003e \n\u003e     _______________________________________________\n\u003e     bitcoin-dev mailing list\n\u003e     bitcoin-dev at lists.linuxfoundation.org\n\u003e     \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e     \u003chttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\u003e\n\u003e \n\u003e \n\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"}