public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Chris Priest <cp368202@ohiou.edu>
To: David Vorick <david.vorick@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released
Date: Sat, 7 Jan 2017 12:26:30 -0800	[thread overview]
Message-ID: <CAAcC9ysNPC1nHumY4giCi7ffVRviNZBNfoLdS0UsghSX8NRcmw@mail.gmail.com> (raw)
In-Reply-To: <CAFVRnyqw2w1rHN=ShLBsadB3henEM9BZxxdXj+4QY6NQAyZ4Fg@mail.gmail.com>

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


  reply	other threads:[~2017-01-07 20:26 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-06 10:16 [bitcoin-dev] Bitcoin Classic 1.2.0 released Tom Zander
2017-01-07  8:13 ` Jonas Schnelli
2017-01-07  8:55 ` Eric Lombrozo
2017-01-07 15:15   ` Tom Zander
2017-01-07 20:12   ` Chris Priest
2017-01-07 20:17     ` David Vorick
2017-01-07 20:26       ` Chris Priest [this message]
2017-01-07 21:14         ` Eric Voskuil
2017-01-07 23:10         ` Aymeric Vitte
2017-01-07 23:49           ` Eric Voskuil
2017-01-08  0:28             ` Eric Lombrozo
2017-01-08  1:58               ` Chris Priest
2017-01-07 21:15     ` Btc Drak
2017-01-07 23:08       ` Tom Zander
2017-01-08  0:32   ` Eric Voskuil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAAcC9ysNPC1nHumY4giCi7ffVRviNZBNfoLdS0UsghSX8NRcmw@mail.gmail.com \
    --to=cp368202@ohiou.edu \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=david.vorick@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox