From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E7887412 for ; Sat, 7 Jan 2017 20:18:01 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f51.google.com (mail-lf0-f51.google.com [209.85.215.51]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B35FC10A for ; Sat, 7 Jan 2017 20:18:00 +0000 (UTC) Received: by mail-lf0-f51.google.com with SMTP id m78so51976451lfg.2 for ; Sat, 07 Jan 2017 12:18:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1y845Wt0Yvj1bvZUaHu50zbc8wM5r4LpZQcl7G0psP0=; b=cvWfK0eFuu16vDlzPLnioHSbQUeLjya4wA849cZ1589E9M6iJwJxQS+lvYNtTTnNA0 jHFssJiluSm9MJkx5RhfSbl6W6gp2LfqzVgPG9lBkztNNWB+PvgFLvVh+Oz3qBmxeXRk E9zQCkH8VR37+YoqDulVU4YsctqZhPbMgey7UIkgbCqj42VfzXhJODz6lut8TThiM+wh Tk+8QZ23Um5/fFMBDzknG/I0eRql9P6PHdDs3MdjePN28MAS7p+pMb6X6oGCQCyBc4zM HVEwKm4HGtTzrdfW+EUcoN5QY5wrF+6/61xf93UPRIRT6V93wRksMejQUK002pZ/xsdc /Upw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1y845Wt0Yvj1bvZUaHu50zbc8wM5r4LpZQcl7G0psP0=; b=XMZ1oom/0IcuquDue/RFRnAmxjdwdfSDTIPndcdcvN6yv7OSI2+RJ3W2R8TpoXxT6P fDRREJBMST7dQTiAO9jJpCaA6WIW2m8f4Ot7rUJNkTju/OgwhZz0DaKy5SN47/nu1TpA r/SzAV+9/WIxJI0sp3aC6F14sK2zv/Dx9JLocchEFbR1foNcavXWXLhJoIPN7mBOH/Ua 0oRJE5BS+MI3GTUEa6UX+pi58OV4thMwSpo+3KvvqsiRdNG3sdyHVVAP11XI0OxTE1iW MqBX6hVgwjg6dmqWi5YhoK4st0x4d+FzUl1bOv7my8aD+PBVFfTQp8F1orvYj/b+UBfa FSkw== X-Gm-Message-State: AIkVDXJO77SzYNHM0EU3FjCvBvJi1yU66vdIYnF5I4lc1tNocrI5Jtf19d8TrYP07G1xZ4uwE/RgmRLnW2TF0w== X-Received: by 10.25.210.213 with SMTP id j204mr29381941lfg.65.1483820279016; Sat, 07 Jan 2017 12:17:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.74.195 with HTTP; Sat, 7 Jan 2017 12:17:58 -0800 (PST) Received: by 10.114.74.195 with HTTP; Sat, 7 Jan 2017 12:17:58 -0800 (PST) In-Reply-To: References: <7169224.bI6Cz5OEL8@cherry> From: David Vorick Date: Sat, 7 Jan 2017 15:17:58 -0500 Message-ID: To: Chris Priest , Bitcoin Dev Content-Type: multipart/alternative; boundary=001a114115eca434a2054586d4e1 X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 20:18:02 -0000 --001a114115eca434a2054586d4e1 Content-Type: text/plain; charset=UTF-8 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 > --001a114115eca434a2054586d4e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No, Bitcoin classic only activates if 75% of the _miners_= adopt it. That says nothing about the broader network and indeed is much e= asier to achieve through politicking, bribery, coercion, and other tomfoole= ry as 75% of the hashrate is ultimately only a dozen people or so.

You have plenty of channels through w= hich 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:
B= itcoin 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@li= sts.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<= br> > 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/bitcoin= classic/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@l= ists.linuxfoundation.org> wrote:
>
>> Bitcoin Classic version 1.2.0 is now available from;
>>
>>=C2=A0 <https://bitcoinclassic.com/get= tingstarted.html>
>>
>> This is a new major version release, including new features, vario= us
>> bugfixes and performance improvements.
>>
>> This release marks a change in strategy for Bitcoin Classic, movin= g from
>> the
>> very conservative block size proposal based on compromise to one w= here
>> 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 th= e
>> Bitcoin
>> network using a high quality validating node for a large set of us= e
>> cases.
>> Classic presents top notch quality processes in this release, to h= elp
>> anyone
>> running Bitcoin.
>>
>> We include in this release various projects with the beta label. P= eople
>> who
>> want to use the Classic node as an on-ramp to Bitcoin will find th= em
>> 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 see= n 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/tomscrypt= ochannel
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-d= ev@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
--001a114115eca434a2054586d4e1--