Quote from: hv_ on September 07, 2017, 10:16:47 AM

IMO its never good to restrict base protocols - adding 1000s of lines - technobubble them up. Client impls should do this.

Open source protocols needs to be as simple as possible. Or you stifle things (client imlps, knowledge, adoption,..) to dead. That's exactly what we witness right now and too much alts come and share bitcoin's realm. I'm still a bitcoin maximalist and do not believe only big blockers 7 big bitcoiners do see this.

Sadly this witnessing has been already segregated away due to form politics / big blocker have left and you need to look it up elsewhere. Here (or reddit/bitcoin) you cannot much discuss this in peace and I'm just waiting to see what will happen to good old bitcoin. Still hope for a compromise 'most' can agree on and the first step of this (HongKong,..NYA ) was already done.

Actually, I think that Satoshi designed Bitcoin with soft forks and backward compatibility in mind. Back in 2010, he explained why the design included these potential complexities: to make Bitcoin's base protocol compatible with all sorts of use cases, rather than merely the original standard payment transactions.

Emphasis mine:

Quote from: satoshi on June 17, 2010, 06:46:08 PM

The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime. Because of that, I wanted to design it to support every possible transaction type I could think of. The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time. It would have been an explosion of special cases. The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates. The nodes only need to understand the transaction to the extent of evaluating whether the sender's conditions are met.

The script is actually a predicate. It's just an equation that evaluates to true or false. Predicate is a long and unfamiliar word so I called it script.

The receiver of a payment does a template match on the script. Currently, receivers only accept two templates: direct payment and bitcoin address. Future versions can add templates for more transaction types and nodes running that version or higher will be able to receive them. All versions of nodes in the network can verify and process any new transactions into blocks, even though they may not know how to read them.

The design supports a tremendous variety of possible transaction types that I designed years ago. Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc. If Bitcoin catches on in a big way, these are things we'll want to explore in the future, but they all had to be designed at the beginning to make sure they would be possible later.

There is something to be said for avoiding technical debt. I get that. But that doesn't justify attempting to convince (or coerce) every single Bitcoin user into migrating to a hard forked network. That's what a hard fork entails.