oriented approach of the Omnibus
>> Proposal.
>>
>>
>> This is the best way to maximize value for everyone. We have a real
>> opportunity to collaborate and work together on the same team. The Omnibus
>> Proposal, designed in exact accordance with a powerful industry ag
gt; Proposal, designed in exact accordance with a powerful industry agreement
> and incorporating the feedback and suggestions provided from within both
> the developer community and the community-at-large, stands the best chance
> of uniting everyone under a common front.
>
>
> P
, stands the best chance of
uniting everyone under a common front.
Please, for the love of Bitcoin, let us do our best to cooperate.
[1] https://imgur.com/a/a2oPs
Sent with [ProtonMail](https://protonmail.com) Secure Email.
Original Message
Subject: Re: [bitcoin-dev] Compatibility
- We now are witnessing this... COOP vs LukeJr COOP, vs BIP148 vs BIP149 vs
BIP91 ... how many are there?:
https://xkcd.com/927
- If some miners and exchanges collude to enact a rapid 2MB+Segwit hard
fork coin... and calling it "bitcoin" on major exchanges this could swiftly
fragment the
>>if the community wishes to adopt (by unanimous consensus) a 2 MB block
size hardfork, this is probably the best way to do it right now... Legacy
Bitcoin transactions are given the witness discount, and a block size limit
of 2 MB is imposed.<<
The above decision may quickly become very
I can't think of any resistance to this, but the code, on a tight timeline,
isn't going to be easy. Is anyone volunteering for this?
On May 29, 2017 6:19 AM, "James Hilliard via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> For the reasons listed
>
For the reasons listed
here(https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki#Motivation)
you should have it so that the HF can not lock in unless the existing
BIP141 segwit deployment is activated.
The biggest issue is that a safe HF is very unlikely to be able to be
coded and
