Quote from: Carlton Banks on April 09, 2017, 10:56:04 AM

Quote from: wck on April 09, 2017, 10:34:18 AM

Forcing the Lightning network without any fallback isn't rational engineering. It might be great politics though.

But where's the force though?

On-chain capacity can be improved with efficiency increases. The vaunted improvements to tx encoding would give us 20-30% more blockspace, so the 2.1 MB Segwit would become more like the equivalent of 2.5 MB, but still only actually using 2.1 MB. Schnorr signatures would give us a similar amount of extra space in the witness blocks.

So when the Bitcoin devs have solid proposals to:

Increase on-chain capacity directly from 1MB to 2.1MB
Increase transaction block efficiency to the equivalent of 2.6MB using the encoding we use now (which would be only 1.05 MB)
Increase witness block efficiency to the equivalent of 3.75MB using the encoding we use now (which would be only 3 MB)

Now, what's wrong with compressing an aggregated additional 1.25MB of transactions into the 4MB Segwit permits? Getting 5.25MB worth of transactions, while still only using 4MB total?

And why would you say "that's forcing everyone off-chain". On-chain is important, but so is the blocksize. If we can improve the efficiency of on-chain and keep the blocksize the same, adding more blocksize becomes even more effective, the gain ratio is the same improvement every extra MB in blockszie that gets added.

And what's wrong with doing those efficiency improvements before the blocksize is hiked? We already know the arguments against hiking the blocksize right now, what are the arguments against improving the amount of space each transaction uses to achieve more on-chain capacity? I've never heard someone even try to make an argument against the idea.

And again, the Bitcion devs cannot be construed as "forcing people off chain" when you consider that space-efficiency improvements are available and realistic, or when you concede that the blocksize is getting upped by Segwit. This "forcing" description makes zero sense, the devs are just being cautious and diligent, that's all.

Yet a another set of numbers being thrown around. Seriously why isn't there any consistency when people talk about SegWit?

As for compression goes, it can possible be a boon. It can also bite hard when it doesn't work correctly, I lost a disk full of data once because of that. I'm not against it but it does hurt to have options.

Now I haven't studied the SegWit code, and apparently that is what one would have to do to fully understand it. I did read various descriptions, even 2 different ones from Bitcoin core devs. Granted they may have been talking about different versions of the code but it really sounds like no one is on the same page here. To me as a software developer that is really scary. At a minimum it throws up a flag warning that something pretty complex is going on.

As for what is wrong with changing the block size later, nothing technically. There also wouldn't be any harm in comprising and hiking the block size limit up front. The hard fork scare tactics are just that. I'm not aware of any coin that has died because of a hard fork. What is wrong is all the politics. It creates an environment where no one can be trusted.