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.
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.
There is no client that has an "emergent consensus" which also has SegWit implemented. – MaxSan – 2017-03-23T19:42:34.893
@MaxSan https://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 – 2017-03-23T20:39:58.643Its 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 – 2017-03-23T21:52:53.880
@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 – 2017-03-23T21:55:01.137
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 – 2017-03-23T21:56:51.020
@MaxSan "current circumstances" being latency and bandwidth of currently connected nodes, which might have an economic incentive to improve their connectivity, possibly shifting the kinds of nodes that are connected to the network? (centralization will be an ongoing threat regardless of topic) are there other concerns I'm missing – CQM – 2017-03-23T22:25:55.597
An adversary could make attack blocks by creating hard to verify transactions that scale quadratically, SegWit fixes this and it needs to be implemented before any block size increase without opening up the network to new attack vectors. – MaxSan – 2017-03-23T22:47:26.093
@MaxSan but that particular new attack vector could exist for some time, be exploited, and prompt nodes to also implement segwit? Hm, I thought segregated witness when active was still an optional trust system, so I don't see how it would prevent the prevalence of hard to verify transactions – CQM – 2017-03-24T00:06:14.790