Quote from: The One on May 03, 2017, 01:46:52 AM

Quote from: d5000 on May 03, 2017, 12:09:31 AM

And the 2 MB hard fork should contain also a restriction for legacy transactions. Maybe they can be prohibited and all people owning bitcoins on non-Segwit keys have to transfer them to Segwit addresses.

Can't do that.

Why not? In a hard fork, in theory consensus rules can be changed without restrictions.

Quote

On an isolated network with full blockchain - do a soft fork. If it works then make multi copies of the blockchain. Required a huge degree of trusted parties. [..]

I don't really understand your proposal. Do you mean this for the case "legacy transactions are prohibited" there is a backup for non-upgraded nodes? Well, the idea was to "prohibit legacy transactions", not "prohibit legacy keys" - it would be forever be possible to transfer them to Segwit keys - otherwise, many people would lose their Bitcoins. I think that's what AngryDwarf said here and is also what I meant (I perhaps wasn't precise enough):

Quote from: AngryDwarf on May 03, 2017, 06:12:51 AM

I would consider it might be possible to make them eventually "send only" addresses after a grace period which allows users to change any known public receiving addresses.

Quote from: AngryDwarf on May 03, 2017, 06:12:51 AM

Quote from: d5000

A soft fork is always better if possible because of the "danger of two competing blockchains"

There is no difference between the dangers of a soft fork and a hard fork.
[...]
The only difference is that a soft fork is backwards compatible because its more restrictive set of rules.

From my understanding, in a hard fork for unupgraded nodes it would not be possible to follow the new chain anymore. Even if 95% of all miners agree on a hard fork, unupgraded non-mining nodes would split away and couldn't use Bitcoin anymore in a safe way. In a soft fork with a 95% or even 85% approval by miners the minority unupgraded chain would always be orphaned and no node would follow it.

That's why a hard fork would need much more preparation time. A soft fork could be deployed in a few months, a hard fork needs a year or so to ensure all relevant nodes are upgraded.
(If that's wrong correct me.)

Quote from: Lauda on May 03, 2017, 08:05:50 AM

Quote from: d5000 on May 03, 2017, 12:09:31 AM

So the "grace period" between the Segwit activation and the 2MB activation must be as long as possible (~1 year) to correctly evaluate the danger of "full block spam" (in this case "4 MB block spam").

What if nobody attempts to create such block in order to evaluate it? Are "we" going to spam the main network ourselves for testing purposes?

We could spam the testnet for that if nobody does it. Your point is, I suppose, that someone would hold back spam attacks until the maximal block size becomes big enough (e.g. 8 MB)?

Quote from: Lauda

In regards to forcing people into Segwit addresses: While everyone using SW keys would be an optimal future, forcing them into doing this may set a dangerous precedent.

Wouldn't then the quadratic hashing time problem be unsolved forever? Because the problem seems to be the danger of spam attacks based on that problem, and if non-Segwit tx are possible then a spammer obviously will use them. I think as long as it is possible to transfer non-segwit outputs to segwit keys (non-segwit to non-segwit would be the possibility that would have to be prohibited) the precedent is not dangerous.

Quote from: Lauda

I don't see why we'd need a potential 4 MB block (2 MB + SW) for standard transactions. The mempool would be empty for quite a while.

2 MB + SW in my idea would occur in >2019. If Bitcoin's growth continues at the same speed than until now (30-50% transaction volume growth per year) then we could see pretty full mempools then. OK, maybe not if sidechains or extension blocks are functioning.