Quote from: dogie on February 23, 2016, 06:32:53 PM

Quote from: Quickseller on February 23, 2016, 05:49:42 PM

It is the currently however 0.12 contains some controversial features

What do you consider controversial?

In this particular release, or are you asking what I consider the definition of controversial to be?

If you are asking the former, then I would say:

Replace by fee(RBF):

Quote

Opt-in Replace-by-fee transactions
----------------------------------

It is now possible to replace transactions in the transaction memory pool of
Bitcoin Core 0.12 nodes. Bitcoin Core will only allow replacement of
transactions which have any of their inputs' `nSequence` number set to less
than `0xffffffff - 1`. Moreover, a replacement transaction may only be
accepted when it pays sufficient fee, as described in [BIP 125]
(https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki).

Transaction replacement can be disabled with a new command line option,
`-mempoolreplacement=0`. Transactions signaling replacement under BIP125 will
still be allowed into the mempool in this configuration, but replacements will
be rejected. This option is intended for miners who want to continue the
transaction selection behavior of previous releases.

The `-mempoolreplacement` option is *not recommended* for wallet users seeking
to avoid receipt of unconfirmed opt-in transactions, because this option does
not prevent transactions which are replaceable under BIP 125 from being accepted
(only subsequent replacements, which other nodes on the network that implement
BIP 125 are likely to relay and mine). Wallet users wishing to detect whether
a transaction is subject to replacement under BIP 125 should instead use the
updated RPC calls `gettransaction` and `listtransactions`, which now have an
additional field in the output indicating if a transaction is replaceable under
BIP125 ("bip125-replaceable").

Note that the wallet in Bitcoin Core 0.12 does not yet have support for
creating transactions that would be replaceable under BIP 125.

Fee Market in the mempool:

Quote

Memory pool limiting
--------------------

Previous versions of Bitcoin Core had their mempool limited by checking
a transaction's fees against the node's minimum relay fee. There was no
upper bound on the size of the mempool and attackers could send a large
number of transactions paying just slighly more than the default minimum
relay fee to crash nodes with relatively low RAM. A temporary workaround
for previous versions of Bitcoin Core was to raise the default minimum
relay fee.

Bitcoin Core 0.12 will have a strict maximum size on the mempool. The
default value is 300 MB and can be configured with the `-maxmempool`
parameter. Whenever a transaction would cause the mempool to exceed
its maximum size, the transaction that (along with in-mempool descendants) has
the lowest total feerate (as a package) will be evicted and the node's effective
minimum relay feerate will be increased to match this feerate plus the initial
minimum relay feerate. The initial minimum relay feerate is set to
1000 satoshis per kB.

Bitcoin Core 0.12 also introduces new default policy limits on the length and
size of unconfirmed transaction chains that are allowed in the mempool
(generally limiting the length of unconfirmed chains to 25 transactions, with a
total size of 101 KB). These limits can be overriden using command line
arguments; see the extended help (`--help -help-debug`) for more information.

Both of these features are something that many large stakeholders of Bitcoin feel that will be damaging to Bitcoin over the long term, and are not features that are actively opposed by multiple Bitcoin stakeholders. While these are not consensus rules, both of these features is going to change how the Bitcoin network works and operates and will affect the end user experience of those using Bitcoin. You can disagree or agree with the technical aspects of the above features, however you cannot disagree that the above features are opposed by large stakeholders.

By theymos's own definition of when consensus is reached/not reached, regarding a hard-fork (note 0.12 is not a HF), consensus has not been reached regarding these features:

Quote from: theymos on August 26, 2015, 01:06:17 AM

--snip--consensus:

Create a proposal that has no significant opposition. A proposal has significant opposition if it is strongly opposed by any of: [snip] one large exchange or company (Coinbase, etc.),[snip]
--snip--

--snip--

I believe that f2pool would qualify as a "large company"

Quote from: macbook-air on January 16, 2016, 11:42:49 AM

Policy change announcement: We support the hard fork effort to increase the max block size to 2MB. Seg-wit may be deployed together in this hard fork if it can be ready in time, or it can be merged later. Non-controversial features in the hard fork wishlist, if it does not delay the hard fork process, can be deployed at the same time. The hard fork should be implemented in Core, eventually. Bitcoin Classic, which despite was born on the same day that XT dies, is an attempt that could make the hard fork happen sooner. We welcome Classic. We are going to cease support for FSS-RBF after upgrading to version 0.12, some time in the next few weeks. We may not implement the opt-in RBF feature. We believe that we should do everything we can do to make 0-conf transactions as secure as possible. We do not believe the concept of fee market.

The bold above shows their opposition to these features.

I also believe that Brian Armstrong (Coinbase) and bitpay are not in favor of either the fee market, nor RBF, although I do not have quotes on this currently.

If theymos were to follow the same rules regarding allowing the discussion of XT/classic-like proposals in the Bitcoin section as he does these kinds of features, then discussion about 0.12 should belong in the altcoin section and 0.12 should not be advertised/announced by the forum.