Bitcoin Classic 1.2.0 released
15 messages, 6 to 8 Jan 2017. Started by Tom Zander.
Tom Zander (3), Chris Priest (3), Eric Voskuil (3), Eric Lombrozo (2), Jonas Schnelli, David Vorick, Btc Drak, Aymeric Vitte
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
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>
Quoted text (30 lines)
> 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 >
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:
Quoted text (41 lines)
> 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 >
On Saturday, 7 January 2017 00:55:19 CET Eric Lombrozo wrote:
Quoted text (2 lines)
> 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.
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:
Quoted text (66 lines)
> 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 >> >
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:
Quoted text (80 lines)
> 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 >
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:
Quoted text (99 lines)
> 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 >> >
On 01/07/2017 12:26 PM, Chris Priest via bitcoin-dev wrote:
Quoted text (2 lines)
> ... 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
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:
Quoted text (80 lines)
> 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 >
On Saturday, 7 January 2017 21:15:11 CET Btc Drak via bitcoin-dev wrote:
Quoted text (1 line)
> 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.
Le 07/01/2017 à 21:26, Chris Priest via bitcoin-dev a écrit :
Quoted text (4 lines)
> 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
Quoted text (3 lines)
> 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
Quoted text (3 lines)
> > 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
Quoted text (3 lines)
> 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
On 01/07/2017 03:10 PM, Aymeric Vitte via bitcoin-dev wrote:
Quoted text (3 lines)
> 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
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:
Quoted text (18 lines)
> 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 > >
On 01/07/2017 12:55 AM, Eric Lombrozo via bitcoin-dev wrote:
Quoted text (6 lines)
> 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
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:
Quoted text (30 lines)
> 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 >> >> >