Soft fork definition allows for even the 21 mil cap to be changed

[seweso]

Strictly speaking the soft fork definition as written in the Statement from Bitcoin Core 2016-01-07 allows for even the 21 mil cap to be changed.

A soft fork is a change to consensus rules, in which blocks that would have been valid under the old rules may become invalid under the new rules, but all blocks that would have been invalid under the old rules remain invalid under the new rules.

Under that definition a soft fork like this will be valid, which can basically change anything in the segregated block's format.

It desperately needs an extra sentence like "Transactions valid under the old rules are still accepted in blocks under the new rules".

[petertodd]

The term "soft fork" is a technical term with widely accepted meaning; using a different definition in a statement is confusing and accomplishes nothing.

Note how ironically, you're asking us to add another rule to the definition of a soft fork...

[harding]

It desperately needs an extra sentence like "Transactions valid under the old rules are still accepted in blocks under the new rules".

This is definitely not guaranteed to be the case for soft forks. For example, the BIP66 soft fork made transactions with non-strict-DER signatures invalid inside blocks. I believe the possibility of making someone's locktime'd transaction invalid was even discussed on the -dev mailing list as a risk of the BIP66 fork.

I think the definition provided is the standard definition and I agree with @petertodd that it shouldn't be changed.

[seweso]

Just the be clear, you can change the 21 million limit (in the aforementioned way) and call it a Soft-fork?

[petertodd]

On 10 January 2016 06:48:57 GMT-08:00, Wouter Schut notifications@github.com wrote:

Just the be clear, you can change the 21 million limit (in the
aforementioned way) and call it a Soft-fork?

Yes, although many have used the term "evil soft-fork" to refer to that case.

[seweso]

Evil is very subjective, although probably not at the extremes.

Can we have an objective definition of "Evil Soft fork"? For instance "the fungibility of existing inputs should not be limited in any way when using older software".

For example, the BIP66 soft fork made transactions with non-strict-DER signatures invalid inside blocks.

Was that "evil"? I suspect it still allowed those signatures where still valid for older inputs.

But nevertheless this issue can be closed.

[petertodd]

"Evil" is subjective. For instance, with a large blocksize we're certainly going to have to increase the inflation rate to pay miners to keep the network secure; in that circumstance we may very well have strong consensus that this must be done.

On 10 January 2016 07:09:41 GMT-08:00, Wouter Schut notifications@github.com wrote:

Evil is very subjective, although probably not at the extremes.

Can we have an objective definition of "Evil Soft fork"? For instance
"the fungibility of existing inputs should not be limited in any way
when using older software".

For example, the BIP66 soft fork made transactions with
non-strict-DER signatures invalid inside blocks.

Was that "evil"? I suspect it still allowed those signatures where
still valid for older inputs.

But nevertheless this issue can be closed.

---

Reply to this email directly or view it on GitHub:
#1201 (comment)

[Aquentus]

Where did you get your phd in economics Peter Todd to allow yourself to make such conclusive statements about fees? As you know, a large amount of transactions paying low fees can very well provide for security and, as transaction validation has costs via proof of work, anyone including non fee paying transactions will soon go bankrupt, thus allowing the fees to be set in a free market way to just above cost.

The question was about soft-forks however. If the old nodes "go blind" then I don't think we can still call it a soft fork or even if we can so call it the considerations between that sort of soft fork and a hardfork become the same. Some say that applied to BIP66, but even if not, many are arguing that it definitely applies to SW.

[luke-jr]

I agree some clarification would be appropriate to exclude soft-hardforks.

[luke-jr]

Although note that strictly for the purposes of this statement, the definition used therein is okay, since it is explicitly contrasting softforks with hardforks, and generally soft-hardforks are still preferable to hard-hardforks.

[sandakersmann]

For instance, with a large blocksize we're certainly going to have to increase the inflation rate to pay miners to keep the network secure

@petertodd Not sure if you're trolling or just clueless about economics.

[ABISprotocol]

Though this is closed, I recommend a read through here
https://bitcoin.stackexchange.com/questions/30817/what-is-a-soft-fork
It contains a reference to an older source as well,
https://gist.github.com/gavinandresen/2355445
I don't think it's fair to place hard rules on what a soft fork is, but at the same time there might be some common agreement about what it should be in principle.

The Statement from Bitcoin Core 2016-01-07 says in part,
"A hard fork is a change to consensus rules, in which blocks that would have been invalid under the old rules may become valid under the new rules.

A soft fork is a change to consensus rules, in which blocks that would have been valid under the old rules may become invalid under the new rules, but all blocks that would have been invalid under the old rules remain invalid under the new rules."

The other thing which I referred to above, says in part,
https://bitcoin.stackexchange.com/questions/30817/what-is-a-soft-fork
"What is a Project Fork?

A fork in software development refers to the event of an independent project spinning off from a software project. Such forks sometimes occur in the opensource sphere, when there are irreconcilable plans/goals within a project's community, then often leading to a split in the community and two distinct projects thereafter. In practice this takes form in the sourcecode being copied and henceforth being developed in a different direction independently by the forkers. For example in this conventional sense of fork, Litecoin is a fork of Bitcoin: Litecoin started as a copy of Bitcoin's code-base, but developed into an independent project (although still closely related).
Softfork and Hardfork in Bitcoin terminology

The terms softfork and hardfork in Bitcoin describe compatibility breaking changes in the Bitcoin protocol: Should the community be irreconcilably divided about such an issue, the old version and the new version of Bitcoin could emerge as distinct projects thereafter. While both versions of the Bitcoin protocol are in use, the differences in acceptance may cause a lasting blockchain-fork, i.e. two distinct longest chains which are both considered valid by part of the network.
Softforks are forward compatible

Softforks restrict block acceptance rules in comparison to earlier versions.

New valid blocks are a subset of old valid blocks

The new rules allow a subset of the previous valid blocks, therefore all blocks considered valid by the newer version are also valid in the old version. If at least 51% of the mining power shifts to the new version, the system self-corrects:
Blocks created by old versions of Bitcoin Core that are invalid under the new paradigm might commence a short-term "old-only blockchain-fork", but eventually, they would be overtaken by the chain fork created under the new paradigm, as the hashing power working on the old paradigm would be smaller ("only old versions") than on the new paradigm ("accepted by all versions").
However, if less than 51% of the hashing power switches to the new version, it behaves like a hardfork, and the blockchain-fork will not mend, as the chain created under the old rules has more hashing power and is incompatible to the new rules."

• and -

" there are "soft" rule changes and "hard" rule changes. "Soft" changes tighten up the rules-- old software will accept all the blocks and transactions created by new software, but the opposite may not be true. "Soft" changes do not require the entire network of miners and merchants and users to upgrade or be left behind.

"Hard" changes modify the rules in a way that old, un-upgraded software consider illegal. At this point it is much, much more difficult (some might say impossible) to roll out "hard" changes, because they require every miner and merchant and user to upgrade."

Anyway, just stuff to consider, I suppose.

[kanzure]

ACK re: anything to clarify differences between project forks, git forks, and consensus forks, reorgs, orphans, stales, etc. But not necessarily for a capacity increases FAQ.

re: soft-fork definitions and ambiguity, see http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012173.html