Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal

2017-06-02 Thread Sergio Demian Lerner via bitcoin-dev
ject step forward and >> support the cooperative, compatibility-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 >

Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal

2017-06-02 Thread Jared Lee Richardson via bitcoin-dev
to collaborate and work together on the same team. The Omnibus > 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 chanc

Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal

2017-05-30 Thread CalvinRechner via bitcoin-dev
e community-at-large, 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: [bitcoi

Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal

2017-05-30 Thread Erik Aronesty via bitcoin-dev
- 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 network.

Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal

2017-05-29 Thread Oliver Petruzel via bitcoin-dev
>>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 controver

Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal

2017-05-29 Thread Erik Aronesty via bitcoin-dev
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 > here(https://github.com/bitco

Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal

2017-05-29 Thread James Hilliard via bitcoin-dev
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 tested

[bitcoin-dev] Compatibility-Oriented Omnibus Proposal

2017-05-28 Thread CalvinRechner via bitcoin-dev
This proposal is written under the assumption that the signatories to the Consensus 2017 Scaling Agreement[1] are genuinely committed to the terms of the agreement, and intend to enact the updates described therein. As such, criticisms pertaining to the chosen deployment timeline or hard fork up