Re: [bitcoin-dev] A Segwit2x BIP

[Btc Drak via bitcoin-dev]

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 know this is a draft, but you are seeking reviews of a proposal that has
just a few weeks remaining before deployment (where "technical review" is
pointless because the is not actually open
 unless
you are an approved member
),
making it totally unworkable and irresponsible. For example, exactly how
are other implementations supposed to adopt the BIP in such a short
timeframe? For all the talk of how important "alternative implementations"
are, how does this rash and rushed action promote an ecosystem of multiple
implementors? By encouraging fast upgrades, you are actually centralizing
the ecosystem even further.

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

The draft BIP text looks like an afterthought and doesn't actually specify
the proposal in enough detail to implement from the text. By contrast for
example, BIP141 has a level of detail which allowed others to implement
segwit without looking at any reference code (which consequently results to
more confidence and testing of the specification all round). The Bitcoin
system has a market cap of over $40bn supported by a robust and reliable
network and your proposal is an offence to all Bitcoin has achieved because
due to it's the strong foundations.

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

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



On Fri, Jul 7, 2017 at 10:25 PM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev@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.
>
> 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.
>
> You can find the BIP draft in the following link:
>
> https://github.com/SergioDemianLerner/BIPs/blob/
> master/BIP-draft-sergiolerner-segwit2x.mediawiki
>
> Reference source was kindly provided by the Segwit2x group.
>
> Best regards,
>  Sergio.
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A Segwit2x BIP

[Erik Aronesty via bitcoin-dev]

- 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
others 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 I
am aware of.   If enacted, it will certainly result in two chains - and
with no replay protection..  The results of this will be confusing - two
ledgers with many transactions appearing on both and others appearing only
on one.

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

- The coercion used to drive production of this BIP is mired in a
misinterpretation of BIP9 and sets a precedent for Bitcoin that may
undermine the value prospect of all cryptocurrency in general.   For this
reason alone - even if all of the engineering concerns and timelines are
improved - even assigning this BIP a number could be considered
irresponsible.

- If you still want to code up a fork for the Bitcoin network, consider
starting with Luke's hard fork code and changing the rates of growth as
needed 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 nothing
to do with block size, but could include a timeline for a block size growth
consistent with global average residential bandwidth growth.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev