rich1.0npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwethttps://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetnjumphttps://nostr.ae📅 Original date posted:2017-07-07 📝 Original message:On Fri, Jul 7, 2017 at 10:25 PM, Sergio Demian Lerner via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote: > Hello, > > Here is a BIP that matches the reference code that the Segwit2x group has > built and published a week ago. I'm happy to see that someone has begun writing a specification. But I am appalled to see one just being written now for change it's authors expect to be irreversibly applied to the network in less than 30 days. The timeline of this proposal is recklessly short to such an extreme level that we have never, to the best of my knowledge, seen a prior proposal so hasty. Nowhere does this specification provide justification or assurance that this is at all safe. The time line of it violates the most minimal of responsible engineering practices, by being shorter than even a fast development and release candidate timeframe. This proposal carries an extreme risk for parties to lose money due to transaction reversals at two distinct points in time and provides no proposed countermeasures to avoid these losses. The proposal adds another gratuitous limit to the system: A maximum transaction size where none existed before, yet this limit is almost certainly too small to prevent actual DOS attacks while it is also technically larger than any transaction that can be included today (the largest possible transaction today is 1mb minus the block overheads). The maximum resource usage for maliciously crafted 1MB transaction is enormous and permitting two of them greatly exacerbates the existing vulnerability. > 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 But in a worst case the result would be 8MB, which this document fails to mention. > This is considered safe by many users, companies, miners and academics [2]. The claim that the document's [2] says that these increases are "safe" is incorrect and is a matter which has been previously corrected by the authors of the document: https://www.reddit.com/r/btc/comments/626ud7/coauthor_of_the_paper_that_blockstream_core_keep/dflrshg/ . The cited paper does an approximate best case analysis considering only a couple of risk factors (in particular, block relay time, but ignoring durability to dos attacks, robustness against state intervention, and initial synchronization time) and concluded that 4MB was the largest they could argue was safe. The paper goes on to then argue that even if you crank Bitcoin's parameters to the maximum in those dimensions that it doesn't result in a truly meaningful increase in scalablity-- in effect, it's a weak argument against your proposal and ones like it. > Deploy a modified BIP91 to activate Segwit. The only modification is that the signal "segsignal" is replaced by "segwit2x". This means that BIP-91 and your proposal are indistinguishable on the network, because the string "segsignal" is merely a variable name used in the software. > If segwit2x (BIP91 signal) activates at block N, The proposal is unable to distinguish itself from BIP-91. Does this mean if segwit2x or BIP91 activates ? > This reduces the fee pressure on users and companies creating on-chain transactions, matching market expectations and preventing further market disruption Considering that we just spent the whole weekend with the mempool having ~1 block or less worth of transactions most of the time, it seems highly likely that just activating segwit will substantially disrupt the fee market; to say nothing for the further doubling that isn't even tempered by new wallet adoptions. There seems to be no consideration given to avoiding this disruption and preventing further emergency events when the new capacity is eventually used and software is again left unprepared for having to pay market fees. > and buy time for more comprehensive solutions to be developed and tested In effect, the document admits that it isn't a solution that meaningfully improves the scale or scalablity but rather it's just a bailout to temporarily lower/negate transaction fees. It doesn't seem to make any argument (or even acknowledge) that the risks and disruption are worth its benefit, and it exacerbates those risks by being the product of a closed process and having a timeline shorter than basically any software update for production software (much less the timeframe for any consensus update previously). Kudos for being frank here, but it's not exactly selling itself. It seems to me that the document doesn't really even make an effort to justify the bailout at all and don't explain how it will result in anything except an endless series of additional fee bailouts. Moreover, it doesn't discuss any remediation against the replay exposure that the proposed hardfork is sure to create. ( I can guarantee to you, I will not adopt this hardfork; especially given that is has been made completely clear that the terms of it were set in its closed door meetings and the input of non-supporters was not welcome. )