[Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening?

digitsu jerry.d.chan at bittoku.co.jp
Sat Oct 14 10:28:08 UTC 2017


If this line of argument sounds strangely familiar to those in the list, then it is because Adam, James, Peter, and his supporters have been using the exact same  argument to stop hardforks in the first place, namely, that changing the existing codebase via a hard fork will cause inadvertent chain split and some poor souls who did not get the message to upgrade will lose money.

In this case, as we have the majority of miners signalling segwit2x, and presumably some large proportion of them are actually running btc1, this means that a ‘backing out’ of 2x part now will forcefully fork them off the network and have them waste tens of thousands of dollars a day because they forgot to upgrade.

While Adam and friends seem to care very much about the odd miss-sent payment made due to lack of replay protection, I find it strange that they seem to not care too much about these poor ‘small miners’ that will be inadvertently hurt by a backing out of 2x part.  These are the same ‘small miners’ who struggle to compete with the big ones that James Hilliard is so fond of calling up as an example of mining decentralization worries.

Why should we forget about these innocents?
I don’t see why they are any different than other users.

As Emil O. said, btc1 and segwit2x is already locked in and a large but indeterminate number of miners are already using the software.  (even though they are hard to count, I see this no different than trying to count ‘economic majority’ or ‘user community support’ that the 1x side keeps on claiming to have a majority on.


> On Oct 13, 2017, at 18:11, Dr Adam Back via Bitcoin-segwit2x <bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
> 
> The futures price is 1/3 of 40% so yes actually < 40% hashrate is quite likely.
> 
> https://www.cryptonator.com/rates/BT2-BTC?utm_referrer=https%3a%2f%2fwww.google.com%2f
> 
> Nodes should upgrade because code changes are being made and it's not
> a good idea to run pre-production code on the live network.  Do you
> recall when the company you work for lost bitcoin by running
> pre-release fork code before on the pool?
> 
> Is anyone running BTC1 head in production?  Protecting how much value.
> Reminder this is a public list.
> 
> Adam
> 
> On Fri, Oct 13, 2017 at 11:01 AM, Emil Oldenburg via Bitcoin-segwit2x
> <bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>> The hardfork part is already locked in and is not subject to change. Many
>> btc1 nodes are already deployed and they should not and don't need to
>> update. The only thing left is a potential extra softfork for opt-in replay
>> protection. Only the miners need this softfork.
>> 
>> What makes you think the hardfork will have less than 40% hashpower?
>> 
>> 
>> Emil Oldenburg, CTO
>> Emil at bitcoin.com
>> Visit the all new https://bitcoin.com
>> Wechat: emilold
>> Telegram: emilold
>> 
>> On 2017年10月13日 17:31, Peter BitcoinReminder.com wrote:
>> 
>> Thats not a reason, the BTC1 sourcecode is still in development (f.e. replay
>> protection was reverted just 1-2 days ago?) - so the argument „it can’t be
>> called off“ is just wrong.
>> 
>> So wouldn’t it make sense to add a minimum required hashrate for the HF to
>> lock in? You are really going to fork off with f.e. 40 % hashpower?
>> 
>> 
>> Am 13.10.2017 um 03:42 schrieb Emil Oldenburg via Bitcoin-segwit2x
>> <bitcoin-segwit2x at lists.linuxfoundation.org>:
>> 
>> If we try to be technical here. The HF is already activated, is estimated to
>> trigger in 36 days, and can't be "called off". Nor is there any logic to
>> delay it if hashrate deflects. That's the rules of the btc1 client.
>> 
>> 
>> Emil Oldenburg, CTO
>> Emil at bitcoin.com
>> Visit the all new https://bitcoin.com
>> Wechat: emilold
>> Telegram: emilold
>> 
>> On 2017年10月13日 05:31, John Heathco via Bitcoin-segwit2x wrote:
>> 
>> I don't believe there is an explicitly stated hashpower in which the fork
>> would be "called off", but I would assume it is much lower than what is
>> currently signaling, even if we make the (unwise) assumption that F2Pool
>> would not contribute to mining 2x whatsoever.
>> 
>> 
>> 
>> On Thu, Oct 12, 2017 at 12:57 PM Peter BitcoinReminder.com via
>> Bitcoin-segwit2x <bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>>> 
>>> I’m not Peter Todd, we just share the same (nice) firstname.
>>> 
>>> I still didn’t get an answer what the minimum amount of hashpower is
>>> required, before the fork is getting delayed?
>>> We have to plan time for the whole security measures etc, so I think it’s
>>> reasonable to get more information about this?
>>> 
>>> 
>>> Am 12.10.2017 um 21:53 schrieb bitPico <bitpico at icloud.com>:
>>> 
>>> Without you knowing why they stopped signaling this is FUD and off-topic
>>> for this list. Please instead let F2Pool  state their own opinion here since
>>> yours doesn’t count. If you think your opinion does count then show us your
>>> blocks that your pool has produced; until then you are simply an end-user
>>> and still you are off-topic for this list. If you need ELI5 for how this
>>> list works please let us know and we can help you Peter Todd.
>>> 
>>> Have a groovy day!
>>> 
>>> On Oct 12, 2017, at 8:49 AM, Peter BitcoinReminder.com via
>>> Bitcoin-segwit2x <bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>>> 
>>> Since F2Pool stopped signaling for the NYA[1] and slush also mines mostly
>>> non-NYA blocks, are you still going to fork off in November - splitting the
>>> chain intentionally?
>>> 
>>>>>> [1] https://imgur.com/LgYdFKw
>>> 
>>> _______________________________________________
>>> Bitcoin-segwit2x mailing list
>>> Bitcoin-segwit2x at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Bitcoin-segwit2x mailing list
>>> Bitcoin-segwit2x at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>> 
>> 
>> 
>> _______________________________________________
>> Bitcoin-segwit2x mailing list
>> Bitcoin-segwit2x at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>> 
>> 
>> _______________________________________________
>> Bitcoin-segwit2x mailing list
>> Bitcoin-segwit2x at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Bitcoin-segwit2x mailing list
>> Bitcoin-segwit2x at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>> 
> _______________________________________________
> Bitcoin-segwit2x mailing list
> Bitcoin-segwit2x at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20171014/4a718945/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 874 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20171014/4a718945/attachment.sig>


More information about the Bitcoin-segwit2x mailing list