2

Same as subject. I've been finding it difficult to find any discussion on the current Emergent Consensus implementation and theory, but I have seen reservations.

Does it adversely impact the viability of the current Segregated Witness implementation?

Although I've been bombarded with polarization on these topics, I haven't concluded that they are mutually exclusive.

  • There is no client that has an "emergent consensus" which also has SegWit implemented. – MaxSan Mar 23 '17 at 19:42
  • @MaxSan github.com/bitcoinec/bitcoinec/pull/3 that's not true, bitcoin EC does and you can build from that branch right now if you want, or make your own client that does the same things from scratch. Do you know if emergent consensus impacts the viability of the current segwit implementation? because thats the question – CQM Mar 23 '17 at 20:39
  • Its sort of comparing apples and pasta, once a softfork is activated with segwit, you cant reverse it.... that requires a hardfork to remove it. If different people are accepting different blocks (by size) its not related, although producing ANY non SegWit block would be rejected by the network still. If this is what your asking il flesh out a full response properly? – MaxSan Mar 23 '17 at 21:52
  • @MaxSan right, so people could accept different blocks by size that are also segwit compliant. Thats the obvious answer correct? Primarily looking for validation – CQM Mar 23 '17 at 21:55
  • Correct. EC has its own problems though and there have been papers written that suggest anything above 4Mb would be very bad given current circumstances. – MaxSan Mar 23 '17 at 21:56
1

Technically, there is no reason why the two protocol upgrades couldn't be added to a blockchain in combination. Obviously, they would have to be amended for compatibility in their treatment of blockweight/blocksize. The perceived incompatibility mostly stems from the radically opposed visions the two developer teams appear to have regarding the scaling roadmap of Bitcoin.

SegWit was especially engineered to provide a capacity increase in a way that does not require a hard fork. Many of its proponents appear to expect a hardfork to permanently split the Bitcoin network.

The Emergent Consensus proponents on the other hand appear to take the position that hardforks are preferable to softforks or at least perceive them as much less risky.

Neither of the teams appears to perceive the other proposal as a priority for inclusion into the codebase. A bridge proposal was provided by means of the "BitcoinEC" client that patched the Emergent Consensus feature on top of Bitcoin Core 0.14 which doesn't appear to be maintained anymore though.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.