Quote from: jbreher on May 05, 2017, 05:08:14 PM

Quote from: hobbes on May 05, 2017, 12:48:36 PM

5. Because of a block verification processing time vulnerability that increases quadratically with block size, increasing the block size is only possible AFTER SegWit is active and only for SegWit transactions.

False. Parallel validation routes around quadratic hash time issues, by naturally orphaning blocks that take an inordinate time to verify.

I did not look into it but from what I hear it sounds more like a resource consuming band aid. Why not a proper fix with less CPU cycles?

Quote from: AngryDwarf on May 05, 2017, 05:50:55 PM

Quote from: hobbes on May 05, 2017, 12:48:36 PM

4. There are two possible ways to deploy/implement SegWit, as a softfork or as a hardfork. SegWit as a hardfork would allow a slightly cleaner implementation but would also require replay protection (as the exchanges have specifically asked for lately). SWSF does not require replay protection assuming a hashrate majority. Replay protection is difficult thus SegWit as a hardfork would altogether cause more technical debt than SWSF. Also a hardfork is generally considered of higher risk and would take a longer preparation time.

Sorry, it seems people have had their heads FOHK'ed with (Fear of Hard Fork).

It is not fear but the expectation of 'clusterfuck' (as you put it).

Quote

There is little difference between the dangers of a soft fork and a hard fork.

In the event of a soft fork we have:
1.) The old chain exists with a more permissive set of rules.
2.) The new chain exists with a more restrictive set of rules.

Wait a second, there only exists a single chain as the old chain blocks are being orphaned (I am explicitly talking about a softfork with a hashrate majority as stated above).

Quote

In a hard fork we have:
1.) The old chain exists with a more restrictive set of rules.
2.) The new chain exists with a more permissive set of rules.

So they look exactly the same during a chain split.

No, not at all. With the hard fork the old chain is not 'corrected' to follow the new chain.

Quote

The only difference is that a soft fork is backwards compatible because its more restrictive set of rules.

In the event of a successful soft fork, older nodes continue to operate as normal.
In the event of a successful hard fork, older nodes become unsynced and have to upgrade.

This is a big difference, isn't it?

Quote

In the event of a contentious fork, hard of soft, it becomes an economically damaging clusterfuck until the winning fork is determined (the longest chain) or a bilateral split occurs (the minority chain implements replay protection)*.

Does a 70% hashrate majority still count as contentious? I don't think that would be a big problem for a softfork, the old chain would be forced to go along, but with a hardfork there would certainly remain two chains.

Quote

* Strictly speaking the software forking away from the existing protocol (hard of soft) should be the version that implements relay protection as you cannot demand the existing protocol chain to change its behaviour. In practice though, the aim is not to create a permanent chain split and achieve consensus, so the minority chain should end up orphaned off, and any transactions that occur during any temporary chain split should end up confirmed on the main chain.

How would you implement replay protection for a soft fork, there is only a single chain...

I am considering making my list above a reddit thread as I think it sums up the current situation nicely Grin