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