Re: [bitcoin-dev] A Segwit2x BIP

While BIP91 is probably not terribly harmful, because the vast majority of nodes and users are prepared for it - the hard fork portion of this BIP is being deployed like an emergency patch or quick bug fix to the system. Please consider updating the BIP to include some justification for the

Re: [bitcoin-dev] A Segwit2x BIP

Andrew, Block 475776 and block 477792 (July 26) are the last 2 difficulty adjustment periods before Aug 1st. Charlie On Thu, Jul 13, 2017 at 3:48 PM, Andrew Chow via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > What's special about block 475776? > > On July 13, 2017 12:23:46

Re: [bitcoin-dev] A Segwit2x BIP

What's special about block 475776? On July 13, 2017 12:23:46 PM Sergio Demian Lerner via bitcoin-dev wrote: The BIP has been updated. Changes: - The technical spec has been improved: now the block size increase is specified in terms of weight and not

Re: [bitcoin-dev] A Segwit2x BIP

The BIP has been updated. Changes: - The technical spec has been improved: now the block size increase is specified 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

Re: [bitcoin-dev] A Segwit2x BIP

Well, 40 bytes reduction per input is excessive too :) But 30 bytes reduction will do fine. On Thu, Jul 13, 2017 at 12:10 AM, Sergio Demian Lerner < sergio.d.ler...@gmail.com> wrote: > Some responses.. > >> >> The proposal adds another gratuitous limit to the system: A maximum >> transaction

Re: [bitcoin-dev] A Segwit2x BIP

Some responses.. > > 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

Re: [bitcoin-dev] A Segwit2x BIP

On 12 Jul 2017 2:31 pm, "Tom Zander via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: On Monday, 10 July 2017 20:38:08 CEST Jorge Timón via bitcoin-dev wrote: > I think anything less than 1 year after release of tested code by some > implementation would be irresponsible for any

Re: [bitcoin-dev] A Segwit2x BIP

Le 12/07/2017 à 03:06, Luke Dashjr via bitcoin-dev a écrit : > Even with Core's support, many people would oppose the hardfork > attempt, and it would fail. Why with or without Core support are you sure that it will fail, what can those that are opposing the hardfork attempt do (with or

Re: [bitcoin-dev] A Segwit2x BIP

> Code to support 2x (the hard fork part of the proposal) has been out and > tested for much longer than that. Tested? Where? However, the hardfork part may be out there for a long time but _is still broken_. /jonas signature.asc Description: Message signed with OpenPGP

Re: [bitcoin-dev] A Segwit2x BIP

On Monday 10 July 2017 11:50:33 AM Sergio Demian Lerner via bitcoin-dev wrote: > Regarding the timeline, its certainly rather short, but also is the UASF > BIP 148 ultimatum. BIP148 began with 8 months lead time, reduced to 5 months from popular request and technical considerations. There is

Re: [bitcoin-dev] A Segwit2x BIP

On Mon, Jul 10, 2017 at 1:50 PM, Sergio Demian Lerner via bitcoin-dev wrote: > Regarding the timeline, its certainly rather short, but also is the UASF BIP > 148 ultimatum. This is correct. If you are trying to imply that makes the short timeline here

Re: [bitcoin-dev] A Segwit2x BIP

Thank you for all your comments. I will improve the BIP based on the technical 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 UASF BIP

Re: [bitcoin-dev] A Segwit2x BIP

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

Re: [bitcoin-dev] A Segwit2x BIP

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

Re: [bitcoin-dev] A Segwit2x BIP

On Fri, Jul 7, 2017 at 11:27 PM, Luke Dashjr via bitcoin-dev wrote: > 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, and > should not be a basis for

Re: [bitcoin-dev] A Segwit2x BIP

> Maximum transaction size is kept, to maximize compatibility with current > software and prevent algorithmic and data size DoS's. IIRC, it is actually increased by ~81 bytes, and doesn't count witness data if on Segwit transactions (so in effect, nearly 4 MB transactions are possible). This

Re: [bitcoin-dev] A Segwit2x BIP

On Fri, Jul 7, 2017 at 10:44 PM, Matt Corallo via bitcoin-dev wrote: > This is not a hard fork, simply adding a new limit is a soft fork. You > appear to be confused - as originally written, AFAIR, Jeff's btc1 branch > did not increase the block size, your

Re: [bitcoin-dev] A Segwit2x BIP

On Fri, Jul 7, 2017 at 10:25 PM, Sergio Demian Lerner via bitcoin-dev 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

Re: [bitcoin-dev] A Segwit2x BIP

This is horribly under-specified (ie not possible to implement from what you've written, and your implementation doesn't match at all, last I heard). > Specification > The plain block size is defined as the serialized block size without > witness programs. > Deploy a modified BIP91 to activate

[bitcoin-dev] A Segwit2x BIP

Hello, Here is a BIP that matches the reference code that the Segwit2x group has built and published a week ago. This BIP and code satisfies the requests of a large part of the Bitcoin community for a moderate increase in the Bitcoin non-witness block space coupled with the activation of Segwit.