{"type":"rich","version":"1.0","author_name":"npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","author_url":"https://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-07-07\n📝 Original message:On Fri, Jul 7, 2017 at 10:25 PM, Sergio Demian Lerner via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e Hello,\n\u003e\n\u003e Here is a BIP that matches the reference code that the Segwit2x group has\n\u003e built and published a week ago.\n\nI'm happy to see that someone has begun writing a specification. But I\nam appalled to see one just being written now for change it's authors\nexpect to be irreversibly applied to the network in less than 30 days.\n\nThe timeline of this proposal is recklessly short to such an extreme\nlevel that we have never, to the best of my knowledge, seen a prior\nproposal so hasty.  Nowhere does this specification provide\njustification or assurance that this is at all safe.  The time line of\nit violates the most minimal of responsible engineering practices, by\nbeing shorter than even a fast development and release candidate\ntimeframe.   This proposal carries an extreme risk for parties to lose\nmoney due to transaction reversals at two distinct points in time and\nprovides no proposed countermeasures to avoid these losses.\n\nThe proposal adds another gratuitous limit to the system: A maximum\ntransaction size where none existed before, yet this limit is almost\ncertainly too small to prevent actual DOS attacks while it is also\ntechnically larger than any transaction that can be included today\n(the largest possible transaction today is 1mb minus the block\noverheads).  The maximum resource usage for maliciously crafted 1MB\ntransaction is enormous and permitting two of them greatly exacerbates\nthe existing vulnerability.\n\n\u003e Assuming the current transaction pattern is replicated in a 2 MB plain-sized block that is 100% filled with transactions, then the witness-serialized block would occupy 3.6 MB\n\nBut in a worst case the result would be 8MB, which this document fails\nto mention.\n\n\u003e This is considered safe by many users, companies, miners and academics [2].\n\nThe claim that the document's [2] says that these increases are \"safe\"\nis incorrect and is a matter which has been previously corrected by\nthe authors of the document:\nhttps://www.reddit.com/r/btc/comments/626ud7/coauthor_of_the_paper_that_blockstream_core_keep/dflrshg/\n.\n\nThe cited paper does an approximate best case analysis considering\nonly a couple of risk factors (in particular, block relay time, but\nignoring durability to dos attacks, robustness against state\nintervention, and initial synchronization time) and concluded that 4MB\nwas the largest they could argue was safe. The paper goes on to then\nargue that even if you crank Bitcoin's parameters to the maximum in\nthose dimensions that it doesn't result in a truly meaningful increase\nin scalablity-- in effect, it's a weak argument against your proposal\nand ones like it.\n\n\u003e Deploy a modified BIP91 to activate Segwit. The only modification is that the signal \"segsignal\" is replaced by \"segwit2x\".\n\nThis means that BIP-91 and your proposal are indistinguishable on the\nnetwork, because the string \"segsignal\" is merely a variable name used\nin the software.\n\n\u003e If segwit2x (BIP91 signal) activates at block N,\n\nThe proposal is unable to distinguish itself from BIP-91. Does this\nmean if segwit2x or BIP91 activates ?\n\n\u003e This reduces the fee pressure on users and companies creating on-chain transactions, matching market expectations and preventing further market disruption\n\nConsidering that we just spent the whole weekend with the mempool\nhaving ~1 block or less worth of transactions most of the time, it\nseems highly likely that just activating segwit will substantially\ndisrupt the fee market; to say nothing for the further doubling that\nisn't even tempered by new wallet adoptions.  There seems to be no\nconsideration given to avoiding this disruption and preventing further\nemergency events when the new capacity is eventually used and software\nis again left unprepared for having to pay market fees.\n\n\u003e and buy time for more comprehensive solutions to be developed and tested\n\nIn effect, the document admits that it isn't a solution that\nmeaningfully improves the scale or scalablity but rather it's just a\nbailout to temporarily lower/negate transaction fees.  It doesn't seem\nto make any argument (or even acknowledge) that the risks and\ndisruption are worth its benefit, and it exacerbates those risks by\nbeing the product of a closed process and having a timeline shorter\nthan basically any software update for production software (much less\nthe timeframe for any consensus update previously). Kudos for being\nfrank here, but it's not exactly selling itself.\n\nIt seems to me that the document doesn't really even make an effort to\njustify the bailout at all and don't explain how it will result in\nanything except an endless series of additional fee bailouts.\n\nMoreover, it doesn't discuss any remediation against the replay\nexposure that the proposed hardfork is sure to create. ( I can\nguarantee to you, I will not adopt this hardfork; especially given\nthat is has been made completely clear that the terms of it were set\nin its closed door meetings and the input of non-supporters was not\nwelcome. )"}