Suggest To Add The latest Version Of BitcoinCore To News

[Beraturker]

Hello,

I suggest to add the Latest version: 0.12.0 of Bitcoin Core link to bitcointalk.org

Thanks...

[Quickseller]

It is the currently however 0.12 contains some controversial features and IMO shouldn't be promoted by the forum. I know that I personally won't be upgrading to 0.12

I would think that the "new" tag is inappropriate for the above reasons

[dogie]

It is the currently however 0.12 contains some controversial features

What do you consider controversial?

[venan]

Hello,

I suggest to add the Latest version: 0.12.0 of Bitcoin Core link to bitcointalk.org

Thanks...

can you explain me what this core 0.12.0 means? i dont understand anything. thanks

[LFC_Bitcoin]

It is the currently however 0.12 contains some controversial features and IMO shouldn't be promoted by the forum. I know that I personally won't be upgrading to 0.12

I would think that the "new" tag is inappropriate for the above reasons

Can you elaborate buddy?

[BitHodler]

The message on the front page is more than enough to draw attention as it made me upgrade to 0.12.

[DeathAngel]

The message on the front page is more than enough to draw attention as it made me upgrade to 0.12.

This.

I saw it as soon as I came on here today. Think I'm going to upgrade tomorrow, can't be bothered right now.
Great that a stable version of 0.12.0 is here though finally. I guess the next upgrade will incorporate SegWit.

[Quickseller]

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):

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:

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:

--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"

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. 

[theymos]

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. 

If RBF was a hardfork, there probably wouldn't be sufficient consensus, and 0.12.0 would not be Bitcoin. But RBF and the new mempool policy aren't changes to the consensus rules at all, not even a softfork. The utilitarian reason for the hardfork policy is not because I think that somewhat-controversial changes are inappropriate in general, but because in the specific case of contentious hardforks (and soft-hardforks):
 - Bitcoin is split into two pieces, which is extremely damaging to Bitcoin.
 - There is an attempt to coerce people who agreed to a certain set of "immutable" core consensus rules into abandoning these rules.
These two problems don't exist for softforks or network policy changes. Old nodes continue to follow the rules they agreed to, but they will still be on the same network/currency as new nodes. Likewise, for non-contentious hardforks, Bitcoin is not split, and very few people are disenfranchised.

They're also very good features. The mempool policy is especially useful. I had one node on a somewhat low-memory system that would often crash due to an overly-large mempool, and 0.12.0 fixes that. And RBF will allow for solving the "stuck transaction" problem in future releases. (If I thought that some changes were especially bad/damaging, I'd probably point to some consensus-compatible fork of Core like LJR instead.)

[Quickseller]

- There is an attempt to coerce people who agreed to a certain set of "immutable" core consensus rules into abandoning these rules.
These two problems don't exist for softforks or network policy changes. Old nodes continue to follow the rules they agreed to, but they will still be on the same network/currency as new nodes.

I would disagree with your point that softforks and network policy changes does not affect Bitcoin the same way that a hardfork affects Bitcoin. While yes everyone would still be on the same network/currency, how people and entities interact with the network/currency can potentially change significantly and to the point that major previous uses of the network/currency are no longer possible.

Yes even though full nodes can ignore network policy changes, if even a minority of full nodes adopt a network policy change, anyone not following this changed policy would essentially have a blind eye when looking at which transactions are most likely going to end up on the "final" blockchain.

By (essentially) allowing any unconfirmed transaction to be double spent trivially, RBF and the fee market essentially make it impossible to rely on any unconfirmed transaction ever getting confirmed, which is currently a large part of the Bitcoin economy.   

They're also very good features. The mempool policy is especially useful. I had one node on a somewhat low-memory system that would often crash due to an overly-large mempool, and 0.12.0 fixes that. And RBF will allow for solving the "stuck transaction" problem in future releases. (If I thought that some changes were especially bad/damaging, I'd probably point to some consensus-compatible fork of Core like LJR instead.)

There are very few (proposed) features that do not have any positives to them.

A better solution to a low-memory system crashing due to a large mempool would be larger blocks. The fee market feature makes it so that nodes will receive more (what they believe to be) invalid transactions and will make the differences of what transactions are stored in the mempool vary widely on a node-to-node basis, verses being mostly the same today.


This is also slightly off topic, however is somewhat relevant -- I believe that the policy of considering any contentious hardfork proposal to be an altcoin (eg XT and classic are considered altcoins until if/when their HF is successful) may have some unintended consequences. As you most likely know, in recent days, the mempool has grown to be very large, and the status of the network right now is one that has resulted in many people broadcasting transactions that will not confirm after several days. For the most part, the vast majority of the blocks are essentially as large as they can be. I am not sure if this is some kind of "stress test" or if this is the result of "actual" increased activity by users of Bitcoin. If it the later, then there will eventually be very loud calls for a HF to happen very quickly to increase the maximum block size in order to clear out the backlog of transactions. This could result in a HF that is potentially implemented that is even more contentious then the likes of XT or classic (and will likely have less discussion about), and the time users will have to upgrade (the time from when the "decision" to implement the HF to when it actually gets implemented) will potentially be much less then what was proposed under XT and classic.

I don't know how large a role the moderation policy of bitcointalk and r/bitcoin had on XT failing however I believe it to be a fairly large one. Now XT is essentially dead, and there is a risk that an even more contentious HF will (be attempted to) get implemented. I would argue that a contentious HF via XT (or possibly classic) would not be the best thing to happen to BItcoin (although I disagree on your definition of consensus and "significant opposition", and I believe that both XT and classic make attempts to prevent them from being contentious and a HF to classic might not be contentious), it would be the lesser of two evils.