[2017-04-06]Schism Developing Between Lightning Network and Bitcoin Core Develop

[zhangswujip]

Schism Developing Between Lightning Network and Bitcoin Core Developers
The latest developments in the Cryptowar are what appears to be a developing schism between some Lightning Network developers and contributors to Bitcoin Core after Joseph Poon, a Lightning Network developer, Stephen Pair from BitPay, Christopher Jeffrey from Purse and Fedor Indutny, published an extension blocks proposal that both increases on-chain capacity and fixes malleability.

Discussions are heated in somewhat private conversations with one source calling an exchange between Matt Corallo – a former Blockstream employee and Bitcoin Core developer – and Jospeh Poon, as “nasty.”

In semi-public discussions, Poon said yesterday that “the extension block proposal is… a litmus test for corruption in the Bitcoin community.” He further added that “Core is getting what they want (soft fork plus malleability fix), but oppose due to nonsensical reasons.” Before saying “without the ability to make pragmatic decisions Bitcoin as a project is stagnant and dying.”

Corallo said that “extension blocks are a very bad idea,” before adding that “much of the western businesses I’ve asked have no interest in any extension block proposal.” He was asked to name the businesses by a discussion participant but failed to do so.

Interestingly, Poon said that “a malleability fix simpler than SW is provided on the extension block and Lightning on the extension block is superior to SW.” David Chan clarified to say “lightning is safer because there is a baked in pre-allocated space for two LN transactions per extension block. Helps defend against the catastrophic cascade closure of LN channels.”

Poon told CCN that segwit can still be activated with small changes. Clarifying the on-chain capacity that would be added, he stated it would be 3MB, up to 9MB. He further said that “this includes a malleability fix whose individual component is smaller than segwit, as it does not use the weights and discounting.”

The main criticism by other Bitcoin Core developers appears to be regarding timing. Eric Lambrozo, for example, said it would “lead to further development delays since [it] will still require review, obligatory bikeshedding (i.e. determining DoS parameters), testing, implementation, building ecosystem support, adapting existing applications, etc…”

Some Bitcoin Core developers have called the proposal as “technically sound,” while others have used the general argument against soft-forks and applied it to extension blocks. Overall, it appears opinion among Bitcoin Core supporters, including developers, is mixed.

As for miners, CCN has learned F2Pool supports the proposal. Bitfury and BTCC have not yet clarified their stance. If they do support extension blocks, consensus might be within reach, especially as this proposal is a soft-fork.

That means a chain split is very unlikely according to the usual arguments in favor of soft-forks by Bitcoin Core developers. That’s because old nodes can continue to operate, rather than being cut-off the network as would be the case in a hard-fork. As such, it’s opt-in, according to the extension blocks proposers, as well as backwards compatible.

That also means unanimous consensus is not necessary because it’s opt-in. Those not in favor of the proposal can simply just not upgrade, continuing as they are, while others can use the new features, allowing both groups to co-exist within one chain.

It provides to both sides what they want, according to extension blocks proposers. The bigger blocks side gets on-chain capacity, Bitcoin Core gets a malleability fix, allowing for the Lightning Network and other layer two protocols.

A Grand Compromise?

“This latest move is technically very clever, and politically brilliant.” – Emin Gun Sirer, Cornell Professor, told Forbes. You’d think so, but we’ll have to wait and see as, despite providing a malleability fix, Blockstream current and former employees are strongly arguing against it. Their reasons, however, appear hallow. As stated earlier, they amount to general arguments against soft-forks (despite arguing in favor of soft-forks for years), and arguments that it would lead to further delays.

Poon said that extension blocks were implemented in two weeks, “we can test and deploy within months.” Alex Petrov of Bitfury gave a time estimate of around 5-6 months, that’s this autumn/winter.

If such timeline can indeed be achieved then bitcoin might come out stronger, but seeing as Blockstream employees seem to be against it, any merging in Bitcoin Core appears difficult. The proposers say they will flesh out the details, and while it’s not clear whether a pull request will be made, you’d think they will do so.

In such event, it will all come down to one man, Wladimir J. van der Laan, the current maintainer of Bitcoin Core, who has the power to merge the proposal or otherwise. If he does merge, as he did segwit despite it clearly being highly controversial, then the Cryptowar may be over. If he doesn’t, then so-long bitcoin.

Because this currency can’t continue for much longer with such high fees and sometimes delays of days to move value from a to b in this 21st century. And, while I have no views on this specific proposal, I’d welcome whatever breaks this stalemate because this entire debate is becoming far too boring.

Everything that had to be said has been said. It’s now up to businesses and miners to pick something and just get on with it or users and businesses will continue leaving, as will the focus and attention of those who do sort of continue to stay.
link:https://www.cryptocoinsnews.com/schism-developing-lightning-network-bitcoin-core-developers/

[veleten]

as if the said schism has not been presented for the past six months or so
“Core is getting what they want (soft fork plus malleability fix), but oppose due to nonsensical reasons.”
uhm... no their reasons seem  perfectly sound,imagine that some unknown cotractor
comes to your construction site and starts saying it is shit and it requires rebuilding and here he just has this wonderful blueprint
and then accuses you of ruining the process,yeah the building is not perfect
but the problem is his blueprint is with mistakes and instead of sitting together and fixing what is wrong
they both start to bicker and accuse one another of all the seven deadly sins
hope the upcoming conference will help to resolve some of the issues between the core devloppers and the BU crew
and we,regular users and miners are no longer held hostage in this dispute

[Carlton Banks]

Adam Back (Blockstream CEO and original cypherpunk) was the originator of the extension blocks idea, not Jeffreys and Poon. And Adam Back abandoned further pursuit of his own idea for extension blocks, because it has problems.


Extension blocks creates a 2 tier network, and in a way Segwit does the same. But the Segwit 2 tier structure is far preferable to the 2 tiers with Extension Blocks.


Segwit allows for 2 block types: transaction blocks and witness blocks. The transaction blocks are just the same 1MB blocks we have now, hence why Segwit works as a backwards compatible soft fork. The new witness blocks that Segwit permits cannot contain transaction data, only the signatures for the corresponding transactions in the 1MB block.

So, the 2 tiers with Segwit are like this:

• Nodes that handle both block types, transaction blocks and witness blocks
• Nodes that handle only transaction blocks

So, the way to make your node part of the more complete blockchain (i.e. transaction blocks and witness blocks) is just to use version 13.1 or newer. And because using the new version comes with heaps of other benefits anyway, it's basically win-win, apart arguably from the extra large blockchain we'll have (but that's a compromise everyone knows must happen anyway, and it comes with it's own benefits, i.e. more on-chain transaction capacity)


With Extension blocks, the 2 tiers are like this:

• Nodes that handle both block types, the original 1MB blocks and all or some extension blocks
• Nodes that handle only the original 1MB blocks

The problem with this is that any number of extra parallel blockchains can be branched off from the main-chain using the Jeffreys/Poon proposal. When you receive a transaction from someone sending it from an extension blockchain, you must download the whole of that extra blockchain, upto the block the sender is sending the BTC from. Otherwise, how can your Bitcoin software verify the BTC is the real thing?

Because of this flaw, it can be argued that this idea is at least as bad as Emergent "Consensus" (what a misnomer that expression was), or perhaps even worse. It's maybe even worse for Bitcoin network decentralisation than the original draft of BIP 101 (20MB blocks with exponential growth) proposal.

If the extension block chains are unknown and unknowable in size and number, until you need to download a whole extra blockchain because you need to receive money from that extra blockchain, how can anyone ever know how big the whole set of blockchains actually is?


That's the real issue here. Extension blocks give miners the ability to create an infinite amount of additional Bitcoin blockchains, all potentially needed by the regular user. It gives miners too much power over the network, in a different way, but similarly to EC/BU would do. No wonder miners like it.

[TraderTimm]

Honestly, who gives a flying crap if someone leaves a large open-source project. Happens all the time. You don't see people moaning about the death of Linux because some hayseed quit out in Des Moines, do you?

Open source is more robust than a few individuals.

I concur with Carlton on the extension blocks summary, which incidentally Jihan "fuck your mother if you want fuck" Wu was pushing before he got exposed using the ASICBoost cheat covertly.

That's all you need to know...

[d5000]

The problem with this is that any number of extra parallel blockchains can be branched off from the main-chain using the Jeffreys/Poon proposal. When you receive a transaction from someone sending it from an extension blockchain, you must download the whole of that extra blockchain, upto the block the sender is sending the BTC from. Otherwise, how can your Bitcoin software verify the BTC is the real thing?

I'm only recently investigating the Extension Blocks technique, so my knowledge is incomplete at best.

But couldn't nodes freely choose which "extension blockchains" they want to accept? That would be a similar scenario to sidechains (and alternative chains in general), imho. There would be stronger and weaker "extension blockchains", some more accepted than others, and I doubt that there could be a infinite number of strong extension chains.

What's true is that nodes that depend economically on sales (merchants, payment processors, exchanges) would have to accept the highest possible number of (secure) extension chains. But regular users probably would be fine simply using lite clients and accepting the ~10 strongest extension chains.