Quote from: franky1 on May 08, 2017, 07:43:12 PM

Quote from: hobbes on May 08, 2017, 03:26:23 PM

Please explain how a softfork would cause a chain split. A pool ignoring/banning/rejecting blocks/communication means it diverted from the chain protocol which equals to a chain split in my point of view.

FTFY

a hard chain split is about the nodes(users) doing something to cause 2 chains.
a soft chain split is about the pools doing something to cause 2 chains.

EG a soft chain split is even though nodes dont have to do anything. pools ignore each other purely based on a version number where the pools then decide to either join X or ignore X and build on Y

leading to the nodes that without doing anything end up following what they can happily accept

A node will always follow the longest chain of blocks it considers valid. What have pools to do with it? Once again ignoring version numbers sounds like a protocol violation = hard fork.

Quote

i just read your reddit summary and laughed my head off..

Glad I could entertain you

Quote

you do realise the only establishment causing drama are the portfolio of DCG (blockstream, btcc, coinbase, and more) with all their REKT campaigns, accusations, Pow killing proposals, deadlines, blackmails, bribes.

Never heard about dcg before, quite interesting (though offtopic). Would be interesting to know how much of a stake they hold in all these companies listed on their website. Regarding your accusations I feel these rather come from the BU side (I read both r/btc and r/bitcoin).

Quote

other non blockstream endorsed implementations are just plodding along not making threats and ven laughing at blockstreams attempt to get non-blockstream implementations to split, by simply saying 'no thanks w wanna stay as a peer network'

Sorry, I can't figure out what you are saying here. Undecided

Quote from: jbreher on May 08, 2017, 08:24:23 PM

Quote from: hobbes on May 08, 2017, 12:36:58 PM

But quadratically with block size meaning at 16MB blocks or so a 30% miner might still be able to block all nodes permanently.

No. As I explained (did you even read?), parallel validation routes around the quadratic hash time issue.

Yes I did but I realize now I took a wrong train of thought at some point, sorry.

It's difficult to embrace a solution by someone with a track record as bad as BU recently if there is another more sustainable solution available by someone whose code I used without issue for years.

Quote

I oppose The SegWit Omnibus Changeset mostly due to considerations other than segwit itself.

ok, this move the discussion forward.

Quote

Namely: the SF nature;

As above: SF with hashrate majority safer than hardfork, replay protection is difficult

Quote

the backdoor of versionbit changes;

From the other point of views it allows for easy upgrades. I can't imagine core could pull of anything that really goes against the will of the user majority. People would simply hard fork away. Same if they will not increase the block size if it is safely possible.

Quote

and the centrally-planned magic 4:1 ratio.

Based on historic tx data and expected SW tx sizes I guess? This is concern trolling.

Quote

But mostly because the 1.7x or 2x or whatever capacity increase it ends up being is too little

Better than nothing! And you are completely ignoring we need SegWit regardless of tx capacity.

Quote

, too late,

Faster than anything else.

Quote

and we'll just be back at this same argument before the year is up.

Possibly but by then we have learned more about larger blocks in a safe way. Also we will know more about about lightning and how much time it will be able to buy us. This could make a difference of a factor of ten or more and buy us quite some time. Think of it as an opportunity. We can always hardfork later on.