[bitcoin-dev] Announcements on bitcoin-dev

2017-01-07 Thread Btc Drak via bitcoin-dev
The purpose of this list is Bitcoin protocol discussion of all kinds,
including consensus rules that require hard and soft forks and there
have been many discussions about both. There is also a clear technical
process for proposing, discussing and peer reviewing consensus rule
changes via the BIPs process which this list has traditionally played
a large role. BIP specifications allow community wide coordination
across multiple implementations.

Since the recent thread announcing a new version of Bitcoin Classic,
many people have complained on and off-list that is should not be
allowed on the bitcoin-dev mailing list because it is not consensus
compatible nor is it a change which has been arrived at through wide
community consensus. There isn't even a formal specification that
other implementations could follow if they wanted to. The general
feeling seems to be that announcements for consensus compatible
implementations is ok on this list. If there is ever community wide
consensus for a hard fork, then that too would be ok since there would
be consensus.

This list does strive to be somewhat high signal to noise ratio where
possible and we need to be clear about the list remit. So let's be
clear, announcing/advertising software that is consensus incompatible
is off-topic, however, discussion of hard forks, peer review etc has
always been, and remains, on topic.

I've copied the current list remit below for completeness. General
discussions should be directed at bitcoin-discuss, where as actual
protocol development discussion belongs on bitcoin-dev.

Bitcoin development and protocol discussion.

This list is lightly moderated.

- No offensive posts, no personal attacks.
- Posts must concern development of bitcoin protocol.
- Posts should be technical or academic in nature.
- Generally encouraged: patches, notification of pull requests, BIP
proposals, academic paper announcements. And discussions that follow.
- Generally discouraged: shower thoughts, wild speculation, jokes,
+1s, non-technical bitcoin issues, rehashing settled topics without
new data, moderation concerns.
- Detailed patch discussion generally better on a GitHub PR.
- Meta-discussion is better on bitcoin-discuss
(https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss)

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

2017-01-07 Thread 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
 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
>>
>>
>
___
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

2017-01-07 Thread 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 <
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
>
>
___
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

2017-01-07 Thread Eric Voskuil via bitcoin-dev
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



signature.asc
Description: OpenPGP digital signature
___
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

2017-01-07 Thread Aymeric Vitte via bitcoin-dev


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

___
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

2017-01-07 Thread Tom Zander via bitcoin-dev
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
___
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

2017-01-07 Thread 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 <
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
>  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;
> >>
> >>  
> >>
> >> 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
>
___
bitcoin-dev mailing list

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

2017-01-07 Thread Eric Voskuil via bitcoin-dev
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



signature.asc
Description: OpenPGP digital signature
___
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

2017-01-07 Thread 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.


On 1/7/17, David Vorick  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
>>  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;
>> >>
>> >>  
>> >>
>> >> 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
>>
>
___
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

2017-01-07 Thread 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" <
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
>  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;
> >>
> >>  
> >>
> >> 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
>
___
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

2017-01-07 Thread 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
 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;
>>
>>  
>>
>> 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

2017-01-07 Thread Tom Zander via bitcoin-dev
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
___
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

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

> Bitcoin Classic version 1.2.0 is now available from;
>
>  
>
> 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

2017-01-07 Thread 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


> Bitcoin Classic version 1.2.0 is now available from;
>
>  
>
> 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
>




signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev