[bitcoin-dev] Bitcoin Classic 1.2.0 released

[Tom Zander via bitcoin-dev]

Bitcoin Classic version 1.2.0 is now available from;

<https://bitcoinclassic.com/gettingstarted.html>

This is a new major version release, including new features, various
bugfixes and performance improvements.

This release marks a change in strategy for Bitcoin Classic, moving from the
very conservative block size proposal based on compromise to one where
Classic truly innovates and provides a long term solution for the market to
choose and leave behind the restrictions of the old.

The most visible change in this version is the decentralised block size
solution where node operators decide on the maximum size.

Bitcoin Classic is focused on providing users a way to get onto the Bitcoin
network using a high quality validating node for a large set of use cases.
Classic presents top notch quality processes in this release, to help anyone
running Bitcoin.

We include in this release various projects with the beta label. People who
want to use the Classic node as an on-ramp to Bitcoin will find them
interesting. These projects will need to be enabled in the config by those
that want to test them.

More background information on this release and Classic can be seen in this
video: https://vimeo.com/192789752
The full release notes are on github at
https://github.com/bitcoinclassic/bitcoinclassic/releases/tag/v1.2.0

[Jonas Schnelli via bitcoin-dev]

Hi Tom

Please don't post release announcements for software that is
incompatible with the current bitcoin consensus rules here.
Otherwise we give green-lights to any sorts of altcoin to post their
releases here.

Thanks

</jonas>

Post by Tom Zander via bitcoin-dev
Bitcoin Classic version 1.2.0 is now available from;
<https://bitcoinclassic.com/gettingstarted.html>
This is a new major version release, including new features, various
bugfixes and performance improvements.
This release marks a change in strategy for Bitcoin Classic, moving from the
very conservative block size proposal based on compromise to one where
Classic truly innovates and provides a long term solution for the market to
choose and leave behind the restrictions of the old.
The most visible change in this version is the decentralised block size
solution where node operators decide on the maximum size.
Bitcoin Classic is focused on providing users a way to get onto the Bitcoin
network using a high quality validating node for a large set of use cases.
Classic presents top notch quality processes in this release, to help anyone
running Bitcoin.
We include in this release various projects with the beta label. People who
want to use the Classic node as an on-ramp to Bitcoin will find them
interesting. These projects will need to be enabled in the config by those
that want to test them.
More background information on this release and Classic can be seen in this
video: https://vimeo.com/192789752
The full release notes are on github at
https://github.com/bitcoinclassic/bitcoinclassic/releases/tag/v1.2.0

[Eric Lombrozo via bitcoin-dev]

Your release announcement does not make it clear that Bitcoin Classic is
incompatible with the current Bitcoin network and its consensus rules. It
is a hard fork on mainnet with no safe activation as well as including
other unsafe changes. There is also no BIP for the hard fork. There is also
no evidence of community wide consensus for such a hard fork. This is
dangerous and irresponsible.


It's wrong to announce software without correctly informing people about
the contents or risks. Furthermore, there are no release notes in
https://github.com/bitcoinclassic/bitcoinclassic/tree/v1.2.0/doc nor
changelog. Without those, it is almost impossible for average users to know
what is under the hood or what has changed and time consuming for
developers to assess.

On Fri, Jan 6, 2017 at 2:16 AM, Tom Zander via bitcoin-dev <

Post by Tom Zander via bitcoin-dev
Bitcoin Classic version 1.2.0 is now available from;
<https://bitcoinclassic.com/gettingstarted.html>
This is a new major version release, including new features, various
bugfixes and performance improvements.
This release marks a change in strategy for Bitcoin Classic, moving from the
very conservative block size proposal based on compromise to one where
Classic truly innovates and provides a long term solution for the market to
choose and leave behind the restrictions of the old.
The most visible change in this version is the decentralised block size
solution where node operators decide on the maximum size.
Bitcoin Classic is focused on providing users a way to get onto the Bitcoin
network using a high quality validating node for a large set of use cases.
Classic presents top notch quality processes in this release, to help anyone
running Bitcoin.
We include in this release various projects with the beta label. People who
want to use the Classic node as an on-ramp to Bitcoin will find them
interesting. These projects will need to be enabled in the config by those
that want to test them.
More background information on this release and Classic can be seen in this
video: https://vimeo.com/192789752
The full release notes are on github at
https://github.com/bitcoinclassic/bitcoinclassic/releases/tag/v1.2.0
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Tom Zander via bitcoin-dev]

Post by Eric Lombrozo via bitcoin-dev
Your release announcement does not make it clear that Bitcoin Classic is
incompatible with the current Bitcoin network and its consensus rules.

To explain why I didn't write that;

Bitcoin Classic is not incompatible with the current Bitcoin network and its
consensus rules.

[Chris Priest via bitcoin-dev]

Bitcoin Classic only activates if 75% of the network adopts it. That
is not irresponsible or dangerous. It would only be dangerous if it
activates at 50%, because that would create a situation where its not
clear which side of the fork has the most proof of work.

On 1/7/17, Eric Lombrozo via bitcoin-dev

Post by Eric Lombrozo via bitcoin-dev
Your release announcement does not make it clear that Bitcoin Classic is
incompatible with the current Bitcoin network and its consensus rules. It
is a hard fork on mainnet with no safe activation as well as including
other unsafe changes. There is also no BIP for the hard fork. There is also
no evidence of community wide consensus for such a hard fork. This is
dangerous and irresponsible.
It's wrong to announce software without correctly informing people about
the contents or risks. Furthermore, there are no release notes in
https://github.com/bitcoinclassic/bitcoinclassic/tree/v1.2.0/doc nor
changelog. Without those, it is almost impossible for average users to know
what is under the hood or what has changed and time consuming for
developers to assess.
On Fri, Jan 6, 2017 at 2:16 AM, Tom Zander via bitcoin-dev <

Post by Tom Zander via bitcoin-dev
Bitcoin Classic version 1.2.0 is now available from;
<https://bitcoinclassic.com/gettingstarted.html>
This is a new major version release, including new features, various
bugfixes and performance improvements.
This release marks a change in strategy for Bitcoin Classic, moving from the
very conservative block size proposal based on compromise to one where
Classic truly innovates and provides a long term solution for the market to
choose and leave behind the restrictions of the old.
The most visible change in this version is the decentralised block size
solution where node operators decide on the maximum size.
Bitcoin Classic is focused on providing users a way to get onto the Bitcoin
network using a high quality validating node for a large set of use cases.
Classic presents top notch quality processes in this release, to help anyone
running Bitcoin.
We include in this release various projects with the beta label. People who
want to use the Classic node as an on-ramp to Bitcoin will find them
interesting. These projects will need to be enabled in the config by those
that want to test them.
More background information on this release and Classic can be seen in this
video: https://vimeo.com/192789752
The full release notes are on github at
https://github.com/bitcoinclassic/bitcoinclassic/releases/tag/v1.2.0
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[David Vorick via bitcoin-dev]

No, Bitcoin classic only activates if 75% of the _miners_ adopt it. That
says nothing about the broader network and indeed is much easier to achieve
through politicking, bribery, coercion, and other tomfoolery as 75% of the
hashrate is ultimately only a dozen people or so.

You have plenty of channels through which you can make your announcements,
this particular one is not okay.

On Jan 7, 2017 3:12 PM, "Chris Priest via bitcoin-dev" <

Post by Chris Priest via bitcoin-dev
Bitcoin Classic only activates if 75% of the network adopts it. That
is not irresponsible or dangerous. It would only be dangerous if it
activates at 50%, because that would create a situation where its not
clear which side of the fork has the most proof of work.
On 1/7/17, Eric Lombrozo via bitcoin-dev

Post by Eric Lombrozo via bitcoin-dev
Your release announcement does not make it clear that Bitcoin Classic is
incompatible with the current Bitcoin network and its consensus rules. It
is a hard fork on mainnet with no safe activation as well as including
other unsafe changes. There is also no BIP for the hard fork. There is

also

Post by Eric Lombrozo via bitcoin-dev
no evidence of community wide consensus for such a hard fork. This is
dangerous and irresponsible.
It's wrong to announce software without correctly informing people about
the contents or risks. Furthermore, there are no release notes in
https://github.com/bitcoinclassic/bitcoinclassic/tree/v1.2.0/doc nor
changelog. Without those, it is almost impossible for average users to

know

Post by Eric Lombrozo via bitcoin-dev
what is under the hood or what has changed and time consuming for
developers to assess.
On Fri, Jan 6, 2017 at 2:16 AM, Tom Zander via bitcoin-dev <

Post by Tom Zander via bitcoin-dev
Bitcoin Classic version 1.2.0 is now available from;
<https://bitcoinclassic.com/gettingstarted.html>
This is a new major version release, including new features, various
bugfixes and performance improvements.
This release marks a change in strategy for Bitcoin Classic, moving from the
very conservative block size proposal based on compromise to one where
Classic truly innovates and provides a long term solution for the market to
choose and leave behind the restrictions of the old.
The most visible change in this version is the decentralised block size
solution where node operators decide on the maximum size.
Bitcoin Classic is focused on providing users a way to get onto the Bitcoin
network using a high quality validating node for a large set of use cases.
Classic presents top notch quality processes in this release, to help anyone
running Bitcoin.
We include in this release various projects with the beta label. People who
want to use the Classic node as an on-ramp to Bitcoin will find them
interesting. These projects will need to be enabled in the config by those
that want to test them.
More background information on this release and Classic can be seen in this
video: https://vimeo.com/192789752
The full release notes are on github at
https://github.com/bitcoinclassic/bitcoinclassic/releases/tag/v1.2.0
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Chris Priest via bitcoin-dev]

Bitcoin Classic only changes the block format (by changing the rule
that they have to be 1MB or less). Miners are the only ones who make
blocks, so they are the only ones who mater when it comes to changing
block rules. Nodes, wallets and other software are not affected by
changing block rules. Unlike segwit, where *everybody* has to write
code to support the new transaction format.

Also, it doesn't matter that 75% of hashpower is made up of a dozen
people. That's how the system works, it's not a matter of opinion. If
you are just a node or just a wallet, and you want your voice to
matter, then you need to get a hold of some hashpower.

Post by David Vorick via bitcoin-dev
No, Bitcoin classic only activates if 75% of the _miners_ adopt it. That
says nothing about the broader network and indeed is much easier to achieve
through politicking, bribery, coercion, and other tomfoolery as 75% of the
hashrate is ultimately only a dozen people or so.
You have plenty of channels through which you can make your announcements,
this particular one is not okay.
On Jan 7, 2017 3:12 PM, "Chris Priest via bitcoin-dev" <

Post by Chris Priest via bitcoin-dev
Bitcoin Classic only activates if 75% of the network adopts it. That
is not irresponsible or dangerous. It would only be dangerous if it
activates at 50%, because that would create a situation where its not
clear which side of the fork has the most proof of work.
On 1/7/17, Eric Lombrozo via bitcoin-dev

Post by Eric Lombrozo via bitcoin-dev
Your release announcement does not make it clear that Bitcoin Classic is
incompatible with the current Bitcoin network and its consensus rules. It
is a hard fork on mainnet with no safe activation as well as including
other unsafe changes. There is also no BIP for the hard fork. There is

also

Post by Eric Lombrozo via bitcoin-dev
no evidence of community wide consensus for such a hard fork. This is
dangerous and irresponsible.
It's wrong to announce software without correctly informing people about
the contents or risks. Furthermore, there are no release notes in
https://github.com/bitcoinclassic/bitcoinclassic/tree/v1.2.0/doc nor
changelog. Without those, it is almost impossible for average users to

know

Post by Eric Lombrozo via bitcoin-dev
what is under the hood or what has changed and time consuming for
developers to assess.
On Fri, Jan 6, 2017 at 2:16 AM, Tom Zander via bitcoin-dev <

Post by Tom Zander via bitcoin-dev
Bitcoin Classic version 1.2.0 is now available from;
<https://bitcoinclassic.com/gettingstarted.html>
This is a new major version release, including new features, various
bugfixes and performance improvements.
This release marks a change in strategy for Bitcoin Classic, moving
from
the
very conservative block size proposal based on compromise to one where
Classic truly innovates and provides a long term solution for the
market
to
choose and leave behind the restrictions of the old.
The most visible change in this version is the decentralised block size
solution where node operators decide on the maximum size.
Bitcoin Classic is focused on providing users a way to get onto the Bitcoin
network using a high quality validating node for a large set of use cases.
Classic presents top notch quality processes in this release, to help anyone
running Bitcoin.
We include in this release various projects with the beta label.
People
who
want to use the Classic node as an on-ramp to Bitcoin will find them
interesting. These projects will need to be enabled in the config by those
that want to test them.
More background information on this release and Classic can be seen in this
video: https://vimeo.com/192789752
The full release notes are on github at
https://github.com/bitcoinclassic/bitcoinclassic/releases/tag/v1.2.0
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Eric Voskuil via bitcoin-dev]

... it doesn't matter that 75% of hashpower is made up of a dozen
people. That's how the system works, it's not a matter of opinion.

It's a bug, not a feature.

e

[Aymeric Vitte via bitcoin-dev]

Post by Chris Priest via bitcoin-dev
Bitcoin Classic only changes the block format (by changing the rule
that they have to be 1MB or less). Miners are the only ones who make
blocks, so they are the only ones who mater when it comes to changing
block rules.

Certainly not

Post by Chris Priest via bitcoin-dev
Nodes, wallets and other software are not affected by
changing block rules. Unlike segwit, where *everybody* has to write
code to support the new transaction format.

This is what we could call a decentralized system, when everybody is
affected

Post by Chris Priest via bitcoin-dev
Also, it doesn't matter that 75% of hashpower is made up of a dozen
people. That's how the system works, it's not a matter of opinion.

That's an obvious weakness of the system

Post by Chris Priest via bitcoin-dev
If
you are just a node or just a wallet, and you want your voice to
matter, then you need to get a hold of some hashpower.

Well, probably you did not mean this, this is not fair. "Just a node"...

Still wondering why you guys don't care about the ridiculous number of
full nodes, no incentive to run one and what would happen if someone
were to control a majority of full nodes
--
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

[Eric Voskuil via bitcoin-dev]

Post by Aymeric Vitte via bitcoin-dev
Still wondering why you guys don't care about the ridiculous number of
full nodes, no incentive to run one and what would happen if someone
were to control a majority of full nodes

The level of control over a majority of full nodes is irrelevant. If
this was truly a measure of control over Bitcoin someone would simply
spin up a bunch of nodes and take control at trivial cost.

e

[Eric Lombrozo via bitcoin-dev]

Can you guys please take this discussion elsewhere? Perhaps to
bitcoin-discuss? This is not the place to rehash discussions that have
taken place a million times already. The behavior of the network under
contentious hard forks has been discussed ad nauseum. This mailing list is
for the discussion of new ideas and proposals.

Much appreciated. Thanks.

On Sat, Jan 7, 2017 at 3:49 PM, Eric Voskuil via bitcoin-dev <

Post by Eric Voskuil via bitcoin-dev

Post by Aymeric Vitte via bitcoin-dev
Still wondering why you guys don't care about the ridiculous number of
full nodes, no incentive to run one and what would happen if someone
were to control a majority of full nodes

The level of control over a majority of full nodes is irrelevant. If
this was truly a measure of control over Bitcoin someone would simply
spin up a bunch of nodes and take control at trivial cost.
e
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Chris Priest via bitcoin-dev]

Its too bad you're not the one who decides what gets posted here or
not. If you don't like whats being discussed, then don't open those
emails.

On 1/7/17, Eric Lombrozo via bitcoin-dev

Post by Eric Lombrozo via bitcoin-dev
Can you guys please take this discussion elsewhere? Perhaps to
bitcoin-discuss? This is not the place to rehash discussions that have
taken place a million times already. The behavior of the network under
contentious hard forks has been discussed ad nauseum. This mailing list is
for the discussion of new ideas and proposals.
Much appreciated. Thanks.
On Sat, Jan 7, 2017 at 3:49 PM, Eric Voskuil via bitcoin-dev <

Post by Eric Voskuil via bitcoin-dev

Post by Aymeric Vitte via bitcoin-dev
Still wondering why you guys don't care about the ridiculous number of
full nodes, no incentive to run one and what would happen if someone
were to control a majority of full nodes

The level of control over a majority of full nodes is irrelevant. If
this was truly a measure of control over Bitcoin someone would simply
spin up a bunch of nodes and take control at trivial cost.
e
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Btc Drak via bitcoin-dev]

There actually isn't an activation threshold in Bitcoin Classic. The hard
fork rules are active the moment you install the software. As was noted,
there aren't any release notes, so you can be forgiven for not knowing that
BIP109 support was removed and the proposal rejected. Classic recently
adopted a new set of hard fork rules for which there is no written
specification.

Bitcoin software vendors should take great pains to document software
features and changes from version to version. Bitcoin Core for example,
always has extensive release notes, and a full changelog extracted from the
source code for each version. In the case of consensus rule change
proposals, we follow the BIPs process which exists to help ecosystem-wide
co-ordination. A detailed and complete specification allows others to
re-implement the BIP in their own software and also acts as part of the
consensus building process and peer review process.

There's nothing wrong with hard forks per se, and this list is certain a
good place to discuss proposals, but releasing hard fork software without
establishing community wide consensus and without clearly labelling your
product as such is just not cricket. If I may cast your attention back a
few weeks ago, Johnson Lau released a hard fork client _testnet_ as part of
his research project which was announced on this list. It was clearly
labelled. This Bitcoin Classic announcement was not clearly labelled (and
released on mainnet).


On Sat, Jan 7, 2017 at 8:12 PM, Chris Priest via bitcoin-dev <

Post by Chris Priest via bitcoin-dev
Bitcoin Classic only activates if 75% of the network adopts it. That
is not irresponsible or dangerous. It would only be dangerous if it
activates at 50%, because that would create a situation where its not
clear which side of the fork has the most proof of work.
On 1/7/17, Eric Lombrozo via bitcoin-dev

Post by Eric Lombrozo via bitcoin-dev
Your release announcement does not make it clear that Bitcoin Classic is
incompatible with the current Bitcoin network and its consensus rules. It
is a hard fork on mainnet with no safe activation as well as including
other unsafe changes. There is also no BIP for the hard fork. There is

also

Post by Eric Lombrozo via bitcoin-dev
no evidence of community wide consensus for such a hard fork. This is
dangerous and irresponsible.
It's wrong to announce software without correctly informing people about
the contents or risks. Furthermore, there are no release notes in
https://github.com/bitcoinclassic/bitcoinclassic/tree/v1.2.0/doc nor
changelog. Without those, it is almost impossible for average users to

know

Post by Eric Lombrozo via bitcoin-dev
what is under the hood or what has changed and time consuming for
developers to assess.
On Fri, Jan 6, 2017 at 2:16 AM, Tom Zander via bitcoin-dev <

Post by Tom Zander via bitcoin-dev
Bitcoin Classic version 1.2.0 is now available from;
<https://bitcoinclassic.com/gettingstarted.html>
This is a new major version release, including new features, various
bugfixes and performance improvements.
This release marks a change in strategy for Bitcoin Classic, moving from the
very conservative block size proposal based on compromise to one where
Classic truly innovates and provides a long term solution for the market to
choose and leave behind the restrictions of the old.
The most visible change in this version is the decentralised block size
solution where node operators decide on the maximum size.
Bitcoin Classic is focused on providing users a way to get onto the Bitcoin
network using a high quality validating node for a large set of use cases.
Classic presents top notch quality processes in this release, to help anyone
running Bitcoin.
We include in this release various projects with the beta label. People who
want to use the Classic node as an on-ramp to Bitcoin will find them
interesting. These projects will need to be enabled in the config by those
that want to test them.
More background information on this release and Classic can be seen in this
video: https://vimeo.com/192789752
The full release notes are on github at
https://github.com/bitcoinclassic/bitcoinclassic/releases/tag/v1.2.0
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Tom Zander via bitcoin-dev]

Post by Btc Drak via bitcoin-dev
There actually isn't an activation threshold in Bitcoin Classic.

Thats partly correct.
There is just not a formal one, there very much is an informal and practical
threshold.

I, and I'm not alone in this, think that a formal vote or an algorithm to
decide something will happen or not reeks too much like central planning and
more importantly that it is too inflexible for real world use.
Its fine for simple upgrades, and we have seen lots of success there.

It would be a mistake to think that miners can just start mining with
Classic and make something that Core doesn't understand. That would have
negative effects and thus won't happen. Less social people will ask why and
maybe ask how we avoid this. They misunderstand the social and economic
parts of Bitcoin.

The block size is an ongoing debate.
I find it very hard to believe that all the people replying in outrage to my
release announcement completely missed this.

I see no point in bringing it up in a BIP or on this list as some central
cabal that can make decisions for or against. It is in actual fact being
decided in the real world, out of yours and my control.

Classic is a tool to that end. No more. No less.

[Eric Voskuil via bitcoin-dev]

Post by Eric Lombrozo via bitcoin-dev
Your release announcement does not make it clear that Bitcoin Classic is
incompatible with the current Bitcoin network and its consensus rules.
It is a hard fork on mainnet with no safe activation as well as
including other unsafe changes. There is also no BIP for the hard fork.
There is also no evidence of community wide consensus for such a hard
fork. This is dangerous and irresponsible.

While I agree with the sentiment, to be fair one should acknowledge that
Bitcoin Core has intentionally implemented two hard forks since Nov
2015. The earlier is released, and I assume the latter will be.

Neither was subject to activation, or prior public debate (see Buried
Deployments threads):

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-November/thread.html

There was at least some internal discussion about whether a BIP should
document the latter having occurred, and that question was put to the list:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-November/013275.html

Some have argued that these are inconsequential changes. I disagree, as
the arguments is base on provably invalid assumptions. Nevertheless, if
hard fork is the threshold criteria here, Core has not met it.

e