This is horribly under-specified (ie not possible to implement from whatyou've written, and your implementation doesn't match at all, last I heard).

SpecificationThe plain block size is defined as the serialized block size withoutwitness programs.Deploy a modified BIP91 to activate Segwit. The only modification isthat the signal "segsignal" is replaced by "segwit2x".

This is not a protocol change. I have no idea why you included it in the"specification" section.

This is not a hard fork, simply adding a new limit is a soft fork. Youappear to be confused - as originally written, AFAIR, Jeff's btc1 branchdid not increase the block size, your specification here matches thatoriginal change, and does not increase the block size.

The block that activates the hard-fork must have a plain block sizegreater than 1 MB.

There is no hard fork, and this would violate consensus rules. Not surewhat you mean. If you do add a hard fork to this BIP, you really need toflip the hard fork bit.

Any transaction with a non-witness serialized size exceeding 1,000,000is invalid.

This is far from sufficient to protect from DoS attacks, you reallyshould take a look through the mailing list archives and read some ofthe old discussions on the issues here.

Matt

Hello,Here is a BIP that matches the reference code that the Segwit2x grouphas built and published a week ago.This BIP and code satisfies the requests of a large part of the Bitcoincommunity for a moderate increase in the Bitcoin non-witness block spacecoupled with the activation of Segwit.https://github.com/SergioDemianLerner/BIPs/blob/master/BIP-draft-sergiolerner-segwit2x.mediawikiReference source was kindly provided by the Segwit2x group.Best regards,Sergio._______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Post by Matt Corallo via bitcoin-devThis is not a hard fork, simply adding a new limit is a soft fork. Youappear to be confused - as originally written, AFAIR, Jeff's btc1 branchdid not increase the block size, your specification here matches thatoriginal change, and does not increase the block size.

Indeed, their code previously did not increase the blocksize but itwas adjusted at the last minute to do so-- so it may actually do thatnow. Because they don't appear to have implemented any tests for it, Iwouldn't be too surprised if it still didn't work at all but alsowouldn't be surprised if it did.

You are correct that the specification text appears to refer to theprior change that did not. (In my response I just assumed that itmeant what they actually did-- good catch).

I'm happy to see that someone has begun writing a specification. But Iam appalled to see one just being written now for change it's authorsexpect to be irreversibly applied to the network in less than 30 days.

The timeline of this proposal is recklessly short to such an extremelevel that we have never, to the best of my knowledge, seen a priorproposal so hasty. Nowhere does this specification providejustification or assurance that this is at all safe. The time line ofit violates the most minimal of responsible engineering practices, bybeing shorter than even a fast development and release candidatetimeframe. This proposal carries an extreme risk for parties to losemoney due to transaction reversals at two distinct points in time andprovides no proposed countermeasures to avoid these losses.

The proposal adds another gratuitous limit to the system: A maximumtransaction size where none existed before, yet this limit is almostcertainly too small to prevent actual DOS attacks while it is alsotechnically larger than any transaction that can be included today(the largest possible transaction today is 1mb minus the blockoverheads). The maximum resource usage for maliciously crafted 1MBtransaction is enormous and permitting two of them greatly exacerbatesthe existing vulnerability.

The claim that the document's [2] says that these increases are "safe"is incorrect and is a matter which has been previously corrected bythe 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 consideringonly a couple of risk factors (in particular, block relay time, butignoring durability to dos attacks, robustness against stateintervention, and initial synchronization time) and concluded that 4MBwas the largest they could argue was safe. The paper goes on to thenargue that even if you crank Bitcoin's parameters to the maximum inthose dimensions that it doesn't result in a truly meaningful increasein scalablity-- in effect, it's a weak argument against your proposaland ones like it.

Considering that we just spent the whole weekend with the mempoolhaving ~1 block or less worth of transactions most of the time, itseems highly likely that just activating segwit will substantiallydisrupt the fee market; to say nothing for the further doubling thatisn't even tempered by new wallet adoptions. There seems to be noconsideration given to avoiding this disruption and preventing furtheremergency events when the new capacity is eventually used and softwareis again left unprepared for having to pay market fees.

In effect, the document admits that it isn't a solution thatmeaningfully improves the scale or scalablity but rather it's just abailout to temporarily lower/negate transaction fees. It doesn't seemto make any argument (or even acknowledge) that the risks anddisruption are worth its benefit, and it exacerbates those risks bybeing the product of a closed process and having a timeline shorterthan basically any software update for production software (much lessthe timeframe for any consensus update previously). Kudos for beingfrank here, but it's not exactly selling itself.

It seems to me that the document doesn't really even make an effort tojustify the bailout at all and don't explain how it will result inanything except an endless series of additional fee bailouts.

Moreover, it doesn't discuss any remediation against the replayexposure that the proposed hardfork is sure to create. ( I canguarantee to you, I will not adopt this hardfork; especially giventhat is has been made completely clear that the terms of it were setin its closed door meetings and the input of non-supporters was notwelcome. )

Post by Gregory Maxwell via bitcoin-devThe proposal adds another gratuitous limit to the system: A maximumtransaction size where none existed before, yet this limit is almostcertainly too small to prevent actual DOS attacks while it is alsotechnically larger than any transaction that can be included today(the largest possible transaction today is 1mb minus the blockoverheads). The maximum resource usage for maliciously crafted 1MBtransaction is enormous and permitting two of them greatly exacerbatesthe existing vulnerability.

I think that limiting the maximum transaction size may not be the bestpossible solution to the N^2 hashing problem, yet it is not a bad start.

There are several viable soft-forking solutions to it:

1- Soft-fork to perform periodic reductions in the maximum non-segwitchecksigs per input (down to 20)2- Soft-fork to perform periodic reductions in the number of non-segwitchecksigs per transaction. (down to 5K)3- Soft-fork to perform periodic reductions in the amount of data hashed bynon-segwit checksigs.

Regardless which one one picks, the soft-fork can be deployed with enoughtime in advance to reduce the exposure. The risk is still low. Four yearshave passed since I reported this vulnerability and yet nobody hasexploited it. The attack is highly anti-economical, yet every discussionabout the block size ends up citing this vulnerability.

plain-sized block that is 100% filled with transactions, then thewitness-serialized block would occupy 3.6 MBBut in a worst case the result would be 8MB, which this document failsto mention.

I will mention this worst case in the BIP.

Even if artificially filling the witness space up to 8 MB isanti-economical, Segwit exacerbates this problem because each witness bytecosts 1/4th of a non-witness byte, so the block bloat attack gets cheaperthan before. I think the guilt lies more in Segwit discount factor than inthe plain block size increase.I would remove the discount factor altogether, and add a fixed (40 bytes)discount for each input with respect to outputs (not for certain inputtypes), to incentivize the cleaning of the UTXO set. A discount for inputscannot be used to bloat an unlimited number of blocks, because for eachinput the attacker needs to first create an output (without discount).There is no need to incentivize removing the signatures from blocks,because there is already an incentive to do so to save disk space.

that the signal "segsignal" is replaced by "segwit2x".This means that BIP-91 and your proposal are indistinguishable on thenetwork, because the string "segsignal" is merely a variable name usedin the software.No, it is exposed to the rpc mining interface (getblocktemplate). It must

Post by Gregory Maxwell via bitcoin-devThe proposal adds another gratuitous limit to the system: A maximumtransaction size where none existed before, yet this limit is almostcertainly too small to prevent actual DOS attacks while it is alsotechnically larger than any transaction that can be included today(the largest possible transaction today is 1mb minus the blockoverheads). The maximum resource usage for maliciously crafted 1MBtransaction is enormous and permitting two of them greatly exacerbatesthe existing vulnerability.

I think that limiting the maximum transaction size may not be the bestpossible solution to the N^2 hashing problem, yet it is not a bad start.1- Soft-fork to perform periodic reductions in the maximum non-segwitchecksigs per input (down to 20)2- Soft-fork to perform periodic reductions in the number of non-segwitchecksigs per transaction. (down to 5K)3- Soft-fork to perform periodic reductions in the amount of data hashedby non-segwit checksigs.Regardless which one one picks, the soft-fork can be deployed with enoughtime in advance to reduce the exposure. The risk is still low. Four yearshave passed since I reported this vulnerability and yet nobody hasexploited it. The attack is highly anti-economical, yet every discussionabout the block size ends up citing this vulnerability.,

plain-sized block that is 100% filled with transactions, then thewitness-serialized block would occupy 3.6 MBBut in a worst case the result would be 8MB, which this document failsto mention.

I will mention this worst case in the BIP.Even if artificially filling the witness space up to 8 MB isanti-economical, Segwit exacerbates this problem because each witness bytecosts 1/4th of a non-witness byte, so the block bloat attack gets cheaperthan before. I think the guilt lies more in Segwit discount factor than inthe plain block size increase.I would remove the discount factor altogether, and add a fixed (40 bytes)discount for each input with respect to outputs (not for certain inputtypes), to incentivize the cleaning of the UTXO set. A discount for inputscannot be used to bloat an unlimited number of blocks, because for eachinput the attacker needs to first create an output (without discount).There is no need to incentivize removing the signatures from blocks,because there is already an incentive to do so to save disk space.

that the signal "segsignal" is replaced by "segwit2x".This means that BIP-91 and your proposal are indistinguishable on thenetwork, because the string "segsignal" is merely a variable name usedin the software.No, it is exposed to the rpc mining interface (getblocktemplate). It must

IIRC, it is actually increased by ~81 bytes, and doesn't count witness data ifon Segwit transactions (so in effect, nearly 4 MB transactions are possible).This probably doesn't make the hashing problem worse, however it should bemade clear in the BIP.

Assuming the current transaction pattern is replicated in a 2 MBplain-sized block that is 100% filled with transactions, then thewitness-serialized block would occupy 3.6 MB [1]. This is considered safeby many users, companies, miners and academics [2].

Citations do not support the claim.

The plain block size is defined as the serialized block size withoutwitness programs.

This is deceptive and meaningless. There is no reason to *ever* refer to thesize of the block serialised without witness programs. It is not a meaningfulnumber.

Deploy a modified BIP91 to activate Segwit. The only modification is thatthe signal "segsignal" is replaced by "segwit2x".

What is modified here? "segsignal" does not appear in the BIP 91 protocol atall...

If segwit2x (BIP91 signal) activates at block N, then block N+12960activates a new plain block size limit of 2 MB (2,000,000 bytes). In thiscase, at block N+12960 a hard-fork occurs.

A "plain block size limit" of 2 MB would be a no-op. It would have literallyno effect whatsoever on the network rules.

Furthermore, this does not match what btc1/Segwit2x currently implements atall. The actual implementation is: If Segwit (via deployment method) activatesat block N, then block N+12960 activates a new weight limit of 8M (whichcorresponds to a size of up to 8,000,000 bytes).

Any transaction with a non-witness serialized size exceeding 1,000,000 isinvalid.

What is the rationale for excluding witness data from this measurement?

In the short term, an increase is needed to continue to facilitate networkgrowth, and buy time...

Actual network growth does not reflect a pattern that supports this claim.

This reduces the fee pressure on users and companies creating on-chaintransactions, matching market expectations and preventing further marketdisruption.

Larger block sizes is not likely to have a meaningful impact on fee pressure.Any expectations that do not match the reality are merely misguided, andshould not be a basis for changing Bitcoin.

Post by Luke Dashjr via bitcoin-devLarger block sizes is not likely to have a meaningful impact on fee pressure.Any expectations that do not match the reality are merely misguided, andshould not be a basis for changing Bitcoin.

I think it's very clear that they will in the very short term(https://anduck.net/bitcoin/fees/4320_blocks.php note the rate dropswhen demand falls below supply). But I agree with you if you mean asomewhat longer term e.g. a year out.

- The BIP91 portion of the fork seems OK to me. There are some issues withtiming, but since this is for miner coordination of segwit activation, andhas little to do with other network users, it could be included as anoption. (I'm a fan of adding options;plugins, etc. to Bitcoin... someothers aren't.)

- This hard fork portion of the proposal is being deployed with "emergency"speed... even though there is not an emergency on the network today that Iam aware of. If enacted, it will certainly result in two chains - andwith no replay protection.. The results of this will be confusing - twoledgers with many transactions appearing on both and others appearing onlyon one.

- The BIP should be modified to provide evidence and justification for thetimeline that is consistent with the level of risk the network would bearif it were enacted.

- The coercion used to drive production of this BIP is mired in amisinterpretation of BIP9 and sets a precedent for Bitcoin that mayundermine the value prospect of all cryptocurrency in general. For thisreason alone - even if all of the engineering concerns and timelines areimproved - even assigning this BIP a number could be consideredirresponsible.

- If you still want to code up a fork for the Bitcoin network, considerstarting with Luke's hard fork code and changing the rates of growth asneeded for your desired effect. Also you might want to read this first(code references are in there):https://petertodd.org/2016/hardforks-after-the-segwit-blocksize-increase .Plans are already underway for a hard fork, for reasons that have nothingto do with block size, but could include a timeline for a block size growthconsistent with global average residential bandwidth growth.

I am utterly appalled by this proposal both technically, ethically, and bythe process which it has adopted. Hard forks require consensus from theentire ecosystem in order to prevent a fork, funds loss, confusion and harmto the robust guarantees of the Bitcoin system has thus far displayed.

I know this is a draft, but you are seeking reviews of a proposal that hasjust a few weeks remaining before deployment (where "technical review" ispointless because the is not actually open<https://pastebin.com/kktB1kaw> unlessyou are an approved member<https://github.com/btc1/bitcoin/commit/1719c872b6624c37b0f2d94e7a4a2656fac4804a#diff-6a3371457528722a734f3c51d9238c13>),making it totally unworkable and irresponsible. For example, exactly howare other implementations supposed to adopt the BIP in such a shorttimeframe? For all the talk of how important "alternative implementations"are, how does this rash and rushed action promote an ecosystem of multipleimplementors? By encouraging fast upgrades, you are actually centralizingthe ecosystem even further.

The linked coded doesn't uniquely identify itself on the network byuser-agent, something all distinct implementations have done to date.

The draft BIP text looks like an afterthought and doesn't actually specifythe proposal in enough detail to implement from the text. By contrast forexample, BIP141 has a level of detail which allowed others to implementsegwit without looking at any reference code (which consequently results tomore confidence and testing of the specification all round). The Bitcoinsystem has a market cap of over $40bn supported by a robust and reliablenetwork and your proposal is an offence to all Bitcoin has achieved becausedue to it's the strong foundations.

I cannot not support this proposal in the current form and timeline, nor doI support the coercion that has been used behind closed doors to try andgain more support (not limited to, but including approaching companyinvestors to twist arms and veiled threats of blacklisting companies fromfurther funding/collaboration).

I think the best you can hope for this hard fork proposal is for it to bequietly ignored.

Post by Sergio Demian Lerner via bitcoin-devHello,Here is a BIP that matches the reference code that the Segwit2x group hasbuilt and published a week ago.This BIP and code satisfies the requests of a large part of the Bitcoincommunity for a moderate increase in the Bitcoin non-witness block spacecoupled with the activation of Segwit.https://github.com/SergioDemianLerner/BIPs/blob/master/BIP-draft-sergiolerner-segwit2x.mediawikiReference source was kindly provided by the Segwit2x group.Best regards,Sergio._______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Thank you for all your comments. I will improve the BIP based on thetechnical suggestions received.

On the subjective/political side that has slipped into this discussion.Skip this part if not interested in politics.

Regarding the timeline, its certainly rather short, but also is the UASFBIP 148 ultimatum.

If Bitcoin were a democracy and we had somehow a way to securely perform areferendum, then this will solve easily. But neither is true. At least now.

More than 80% of the miners and many users are willing to go in theSegwit2x direction. With the support and great talent of the Bitcoin Coredevelopers, Segwit2x activation will not cause any major disruptions.Without Core, there will be a temporary split. Both sides will have tohard-fork.

I want a Bitcoin united. But maybe a split of Bitcoin, each side with itsown vision, is not so bad.

I don't feel threatened by investors. You're full of shit btcdrak.Proofread your emails. You just declared support for segwit2x.I am utterly appalled by this proposal both technically, ethically, and bythe process which it has adopted. Hard forks require consensus from theentire ecosystem in order to prevent a fork, funds loss, confusion and harmto the robust guarantees of the Bitcoin system has thus far displayed.I know this is a draft, but you are seeking reviews of a proposal that hasjust a few weeks remaining before deployment (where "technical review" ispointless because the is not actually open <https://pastebin.com/kktB1kaw> unlessyou are an approved member<https://github.com/btc1/bitcoin/commit/1719c872b6624c37b0f2d94e7a4a2656fac4804a#diff-6a3371457528722a734f3c51d9238c13>),making it totally unworkable and irresponsible. For example, exactly howare other implementations supposed to adopt the BIP in such a shorttimeframe? For all the talk of how important "alternative implementations"are, how does this rash and rushed action promote an ecosystem of multipleimplementors? By encouraging fast upgrades, you are actually centralizingthe ecosystem even further.The linked coded doesn't uniquely identify itself on the network byuser-agent, something all distinct implementations have done to date.The draft BIP text looks like an afterthought and doesn't actually specifythe proposal in enough detail to implement from the text. By contrast forexample, BIP141 has a level of detail which allowed others to implementsegwit without looking at any reference code (which consequently results tomore confidence and testing of the specification all round). The Bitcoinsystem has a market cap of over $40bn supported by a robust and reliablenetwork and your proposal is an offence to all Bitcoin has achieved becausedue to it's the strong foundations.I cannot not support this proposal in the current form and timeline, nordo I support the coercion that has been used behind closed doors to try andgain more support (not limited to, but including approaching companyinvestors to twist arms and veiled threats of blacklisting companies fromfurther funding/collaboration).I think the best you can hope for this hard fork proposal is for it to bequietly ignored.On Fri, Jul 7, 2017 at 10:25 PM, Sergio Demian Lerner via bitcoin-dev <

Post by Sergio Demian Lerner via bitcoin-devHello,Here is a BIP that matches the reference code that the Segwit2x group hasbuilt and published a week ago.This BIP and code satisfies the requests of a large part of the Bitcoincommunity for a moderate increase in the Bitcoin non-witness block spacecoupled with the activation of Segwit.https://github.com/SergioDemianLerner/BIPs/blob/master/BIP-draft-sergiolerner-segwit2x.mediawikiReference source was kindly provided by the Segwit2x group.Best regards,Sergio._______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Regarding the timeline, its certainly rather short, but also is the UASF BIP148 ultimatum.

This is correct. If you are trying to imply that makes the shorttimeline here right, you are falling for a "tu quoque" fallacy.

More than 80% of the miners and many users are willing to go in the Segwit2xdirection.

There's no logical reason I can think of (and I've heard many attemptsat explaining it) for miners to consider segwit bad for Bitcoin butsegwitx2 harmless. But I don't see 80% hashrate support for bip141, soyour claim doesn't seem accurate for the segwit part, let alone themore controversial hardfork part.

I read some people controlling mining pools that control 80% of thehashrate signed a paper saying they would "support segwitimmediately". Either what I read wasn't true, or the signed paper isjust a proof of the signing pool operators word being something wecannot trust.

So where does this 80% figure come from? How can we trust the source?

I want a Bitcoin united. But maybe a split of Bitcoin, each side with itsown vision, is not so bad.

It would be unfortunate to split the network into 2 coins only becauseof lack of patience for deploying non-urgent consensus changes like asize increase or disagreements about the right time schedule.I think anything less than 1 year after release of tested code by someimplementation would be irresponsible for any hardfork, even a verysimple one.

Post by Jorge TimÃ³n via bitcoin-devI think anything less than 1 year after release of tested code by someimplementation would be irresponsible for any hardfork, even a verysimple one.

Good news!

Code to support 2x (the hard fork part of the proposal) has been out andtested for much longer than that.

Not true. It's different code on top of segwit. The first attempt in btc1(very recent) didn't even increased the size (because it changed themeaningless "base size" without touching the weight limit. As for thecurrent code, I don't think it has been properly tested today, let alone"for mucj longer than 1 year.Anyway, I said, one year from tested release. Segwitx2 hasn't beenreleased, has it? If so, too late to discuss a bip imo, the bip may end upbeing different from what has been released due to feedback (unless it isignored again, of course).

Changes:- The technical spec has been improved: now the block size increase isspecified in terms of weight and not in terms of bytes.- The increase in the maximum block sigops after HF has been documented.- Comments added about the worst case block size.

Post by Jorge TimÃ³n via bitcoin-devI think anything less than 1 year after release of tested code by someimplementation would be irresponsible for any hardfork, even a verysimple one.

Good news!Code to support 2x (the hard fork part of the proposal) has been out andtested for much longer than that.Not true. It's different code on top of segwit. The first attempt in btc1(very recent) didn't even increased the size (because it changed themeaningless "base size" without touching the weight limit. As for thecurrent code, I don't think it has been properly tested today, let alone"for mucj longer than 1 year.Anyway, I said, one year from tested release. Segwitx2 hasn't beenreleased, has it? If so, too late to discuss a bip imo, the bip may end upbeing different from what has been released due to feedback (unless it isignored again, of course).--Tom ZanderBlog: https://zander.github.ioVlog: https://vimeo.com/channels/tomscryptochannel_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Post by Sergio Demian Lerner via bitcoin-devThe BIP has been updated.- The technical spec has been improved: now the block size increase isspecified in terms of weight and not in terms of bytes.- The increase in the maximum block sigops after HF has been documented.- Comments added about the worst case block size.Happy weekend! And don't forget to start signaling something before block475776 ! It's just 90 blocks away.Bit 1 or 4,1 or whatever you wish, but please signal something.To the moon!On Wed, Jul 12, 2017 at 2:38 PM, Jorge TimÃ³n via bitcoin-dev <

Post by Jorge TimÃ³n via bitcoin-devI think anything less than 1 year after release of tested code by someimplementation would be irresponsible for any hardfork, even a verysimple one.

Good news!Code to support 2x (the hard fork part of the proposal) has been out andtested for much longer than that.Not true. It's different code on top of segwit. The first attempt in btc1(very recent) didn't even increased the size (because it changed themeaningless "base size" without touching the weight limit. As for thecurrent code, I don't think it has been properly tested today, let alone"for mucj longer than 1 year.Anyway, I said, one year from tested release. Segwitx2 hasn't beenreleased, has it? If so, too late to discuss a bip imo, the bip may end upbeing different from what has been released due to feedback (unless it isignored again, of course).--Tom ZanderBlog: https://zander.github.ioVlog: https://vimeo.com/channels/tomscryptochannel_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Post by Sergio Demian Lerner via bitcoin-devThe BIP has been updated.- The technical spec has been improved: now the block size increase isspecified in terms of weight and not in terms of bytes.- The increase in the maximum block sigops after HF has been documented.- Comments added about the worst case block size.Happy weekend! And don't forget to start signaling something before block475776 ! It's just 90 blocks away.Bit 1 or 4,1 or whatever you wish, but please signal something.To the moon!On Wed, Jul 12, 2017 at 2:38 PM, Jorge TimÃ³n via bitcoin-dev <

Post by Jorge TimÃ³n via bitcoin-devI think anything less than 1 year after release of tested code by someimplementation would be irresponsible for any hardfork, even a verysimple one.

Good news!Code to support 2x (the hard fork part of the proposal) has been out andtested for much longer than that.Not true. It's different code on top of segwit. The first attempt inbtc1 (very recent) didn't even increased the size (because it changed themeaningless "base size" without touching the weight limit. As for thecurrent code, I don't think it has been properly tested today, let alone"for mucj longer than 1 year.Anyway, I said, one year from tested release. Segwitx2 hasn't beenreleased, has it? If so, too late to discuss a bip imo, the bip may end upbeing different from what has been released due to feedback (unless it isignored again, of course).--Tom ZanderBlog: https://zander.github.ioVlog: https://vimeo.com/channels/tomscryptochannel_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

While BIP91 is probably not terribly harmful, because the vast majority ofnodes and users are prepared for it - the hard fork portion of this BIP isbeing deployed like an emergency patch or quick bug fix to the system.

Please consider updating the BIP to include some justification for theurgency of the consensus change, and the reasons for not delaying until abetter engineered solution (spoonet, BIP103, etc.) can be deployed.

Post by Sergio Demian Lerner via bitcoin-devThe BIP has been updated.- The technical spec has been improved: now the block size increase isspecified in terms of weight and not in terms of bytes.- The increase in the maximum block sigops after HF has been documented.- Comments added about the worst case block size.Happy weekend! And don't forget to start signaling something before block475776 ! It's just 90 blocks away.Bit 1 or 4,1 or whatever you wish, but please signal something.To the moon!On Wed, Jul 12, 2017 at 2:38 PM, Jorge TimÃ³n via bitcoin-dev <

Post by Jorge TimÃ³n via bitcoin-devI think anything less than 1 year after release of tested code by someimplementation would be irresponsible for any hardfork, even a verysimple one.

Good news!Code to support 2x (the hard fork part of the proposal) has been out andtested for much longer than that.Not true. It's different code on top of segwit. The first attempt in btc1(very recent) didn't even increased the size (because it changed themeaningless "base size" without touching the weight limit. As for thecurrent code, I don't think it has been properly tested today, let alone"for mucj longer than 1 year.Anyway, I said, one year from tested release. Segwitx2 hasn't beenreleased, has it? If so, too late to discuss a bip imo, the bip may end upbeing different from what has been released due to feedback (unless it isignored again, of course).--Tom ZanderBlog: https://zander.github.ioVlog: https://vimeo.com/channels/tomscryptochannel_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

BIP148 began with 8 months lead time, reduced to 5 months from popular requestand technical considerations. There is nothing about BIP148 that compels anattempted hardfork 90 days later - that could just as well have been 18months.

Post by Sergio Demian Lerner via bitcoin-devMore than 80% of the miners and many users are willing to go in theSegwit2x direction. With the support and great talent of the Bitcoin Coredevelopers, Segwit2x activation will not cause any major disruptions.

That's not true at all. Based on my observations, only approximately 20% ofthe community follow Core's technical lead without significant considerationof their own - and who knows if that would change if Core were to suggestclearly-unsafe block size increases, or attempted to force a hardfork againstconsensus. Even with Core's support, many people would oppose the hardforkattempt, and it would fail.

Why with or without Core support are you sure that it will fail, whatcan those that are opposing the hardfork attempt do (with or withoutCore) and what does "fail" mean here in fact?--Zcash wallets made simple: https://github.com/Ayms/zcash-walletsBitcoin wallets made simple: https://github.com/Ayms/bitcoin-walletsGet the torrent dynamic blocklist: http://peersm.com/getblocklistCheck the 10 M passwords list: http://peersm.com/findmyassAnti-spies and private torrents, dynamic blocklist: http://torrent-live.orgPeersm : http://www.peersm.comtorrent-live: https://github.com/Ayms/torrent-livenode-Tor : https://www.github.com/Ayms/node-TorGitHub : https://www.github.com/Ayms