{"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-07-13\n📝 Original message:Well, 40 bytes reduction per input is excessive too :)\nBut 30 bytes reduction will do fine.\n\nOn Thu, Jul 13, 2017 at 12:10 AM, Sergio Demian Lerner \u003c\nsergio.d.lerner at gmail.com\u003e wrote:\n\n\u003e Some responses..\n\u003e\n\u003e\u003e\n\u003e\u003e The proposal adds another gratuitous limit to the system: A maximum\n\u003e\u003e transaction size where none existed before, yet this limit is almost\n\u003e\u003e certainly too small to prevent actual DOS attacks while it is also\n\u003e\u003e technically larger than any transaction that can be included today\n\u003e\u003e (the largest possible transaction today is 1mb minus the block\n\u003e\u003e overheads).  The maximum resource usage for maliciously crafted 1MB\n\u003e\u003e transaction is enormous and permitting two of them greatly exacerbates\n\u003e\u003e the existing vulnerability.\n\u003e\u003e\n\u003e\u003e\n\u003e I think that limiting the maximum transaction size may not be the best\n\u003e possible solution to the N^2 hashing problem, yet it is not a bad start.\n\u003e\n\u003e There are several viable soft-forking solutions to it:\n\u003e\n\u003e 1- Soft-fork to perform periodic reductions in the maximum non-segwit\n\u003e checksigs per input (down to 20)\n\u003e 2- Soft-fork to perform periodic reductions in the number of non-segwit\n\u003e checksigs per transaction. (down to 5K)\n\u003e 3- Soft-fork to perform periodic reductions in the amount of data hashed\n\u003e by non-segwit checksigs.\n\u003e\n\u003e Regardless which one one picks, the soft-fork can be deployed with enough\n\u003e time in advance to reduce the exposure. The risk is still low. Four years\n\u003e have passed since I reported this vulnerability and yet nobody has\n\u003e exploited it. The attack is highly anti-economical, yet every discussion\n\u003e about the block size ends up citing this vulnerability.\n\u003e\n\u003e ,\n\u003e\n\u003e\u003e \u003e Assuming the current transaction pattern is replicated in a 2 MB\n\u003e\u003e plain-sized block that is 100% filled with transactions, then the\n\u003e\u003e witness-serialized block would occupy 3.6 MB\n\u003e\u003e\n\u003e\u003e But in a worst case the result would be 8MB, which this document fails\n\u003e\u003e to mention.\n\u003e\u003e\n\u003e\n\u003e I will mention this worst case in the BIP.\n\u003e\n\u003e Even if artificially filling the witness space up to 8 MB is\n\u003e anti-economical, Segwit exacerbates this problem because each witness byte\n\u003e costs 1/4th of a non-witness byte, so the block bloat attack gets cheaper\n\u003e than before. I think the guilt lies more in Segwit discount factor than in\n\u003e the plain block size increase.\n\u003e I would remove the discount factor altogether, and add a fixed (40 bytes)\n\u003e discount for each input with respect to outputs (not for certain input\n\u003e types), to incentivize the cleaning of the UTXO set. A discount for inputs\n\u003e cannot be used to bloat an unlimited number of blocks, because for each\n\u003e input the attacker needs to first create an output (without discount).\n\u003e There is no need to incentivize removing the signatures from blocks,\n\u003e because there is already an incentive to do so to save disk space.\n\u003e\n\u003e\n\u003e\u003e\n\u003e\u003e \u003e Deploy a modified BIP91 to activate Segwit. The only modification is\n\u003e\u003e that the signal \"segsignal\" is replaced by \"segwit2x\".\n\u003e\u003e\n\u003e\u003e This means that BIP-91 and your proposal are indistinguishable on the\n\u003e\u003e network, because the string \"segsignal\" is merely a variable name used\n\u003e\u003e in the software.\n\u003e\u003e\n\u003e\u003e No, it is exposed to the rpc mining interface (getblocktemplate). It must\n\u003e be redefined, even if it's not a consensus change.\n\u003e\n\u003e\n\u003e\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170713/23535924/attachment.html\u003e"}