[bitcoin-dev] Bitcoin Classic 1.2.0 released

[bitcoin-dev] Bitcoin Classic 1.2.0 released

[Tom Zander]

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

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

[Jonas Schnelli]

[-- Attachment #1.1: Type: text/plain, Size: 1675 bytes --]

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

[Eric Lombrozo]

[-- Attachment #1: Type: text/plain, Size: 2555 bytes --]

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 <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 4002 bytes --]

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

[Tom Zander]

On Saturday, 7 January 2017 00:55:19 CET Eric Lombrozo wrote:
> 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.

-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

[Chris Priest]

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
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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 <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

[David Vorick]

[-- Attachment #1: Type: text/plain, Size: 3822 bytes --]

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" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > 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 <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> >> 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
> >> bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 5851 bytes --]

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

[Chris Priest]

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.


On 1/7/17, David Vorick <david.vorick@gmail.com> wrote:
> 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" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > 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 <
>> > bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >
>> >> 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
>> >> bitcoin-dev@lists.linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >>
>> >
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 239 bytes --]

On 01/07/2017 12:26 PM, Chris Priest via bitcoin-dev wrote:

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

[Btc Drak]

[-- Attachment #1: Type: text/plain, Size: 4912 bytes --]

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 <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > 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 <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> >> 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
> >> bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 7030 bytes --]

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

[Tom Zander]

On Saturday, 7 January 2017 21:15:11 CET Btc Drak via bitcoin-dev wrote:
> 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.
-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

[Aymeric Vitte]

Le 07/01/2017 à 21:26, Chris Priest via bitcoin-dev a écrit :
> 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

>  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

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

>  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

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 462 bytes --]

On 01/07/2017 03:10 PM, Aymeric Vitte via bitcoin-dev wrote:
> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

[Eric Lombrozo]

[-- Attachment #1: Type: text/plain, Size: 1123 bytes --]

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 <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 01/07/2017 03:10 PM, Aymeric Vitte via bitcoin-dev wrote:
> > 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
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 1732 bytes --]

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 1319 bytes --]

On 01/07/2017 12:55 AM, Eric Lombrozo via bitcoin-dev wrote:
> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

[Chris Priest]

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
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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 <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On 01/07/2017 03:10 PM, Aymeric Vitte via bitcoin-dev wrote:
>> > 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
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>