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

Marcel Jamin marcel at jamin.net
Sat Oct 14 07:38:50 UTC 2017


On 14 October 2017 at 09:02, Jeff Garzik <jeff at bloq.com> wrote:
> "Strong, two-way replay protection" is poorly defined.
>
> Segwit2x is an upgrade to bitcoin, not an altcoin.

I and many others heavily disagree. The simple reality is this: S2X is
incompatible with Bitcoin AND contentious. Miners and business
adopting this approach to "upgrading" will fork themselves off the
bitcoin blockchain. You're trying to define Bitcoin's rules by
strong-arming changes through hashpower. It doesn't bode well for
bitcoin's future if this is actually successful.

> It is an explicit design goal that SPV wallets continue working through the
> fork, following the strongest, most secure chain as they were programmed to
> do.

... tricking them to follow an invalid chain, as SPV can't fully
validate bitcoin's rules. Validity is not solely defined by hashpower.

> Therefore, any method of replay protection that breaks over 10 million
> wallets - greatly exacerbating chain splits - is rejected (and this has been
> communicated repeatedly for months).

It doesn't break wallets at all, it merely fails to automatically (and
unsolicitedly) onboard them onto this WG's fork of bitcoin (=
incompatible consensus rules, new set of developers, new maintainer).

> Put simply, we want most wallets to Just Keep Working. Certain types of
> replay protection break that.

Put simply, you want to take most wallets with you without explicit
consent and certain types of replay protection don't allow you to do
that. You're only offering an opt-out approach requiring user action +
bloat on the incumbent chain.

There are ways to increase bitcoin's capacity without causing a schism
like this. After all, we did just double it. Work with (virtually all)
bitcoin protocol developers, not against them. This merely means
holding off on a hard fork for a while longer, acknowledging that a
safe hard fork that doesn't split the community is a hard thing to do.
As it should be.

And before anyone is going to lecture me again that this is off-topic
for this list (as a blanket defense when things get uncomfortable),
rest assured that this will be my last mail to this list. One way or
another, this will sort itself out.

> On Oct 14, 2017 2:24 AM, "Marcel Jamin via Bitcoin-segwit2x"
> <bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>>
>> I wouldn't consider any opt-in approach as "strong" replay protection.
>> If this WG as NACKed strong two way replay protection, then it's not a
>> safe upgrade path und thus not an implementation honoring the NYA.
>>
>> On 14 October 2017 at 07:53, Jacob Eliosoff <jacob.eliosoff at gmail.com>
>> wrote:
>> > Can I ask that anyone advocating 2-way replay protection (which I also
>> > support) be specific about how they propose it be done?  No disrespect
>> > meant, but BCH-style RP, that would require old wallets to upgrade, has
>> > been
>> > proposed and emphatically NACKed here umpteen times: it is just
>> > unrealistic
>> > to think this project would adopt it at this stage.  There are other
>> > 2-way
>> > RP approaches that I still believe are worth pursuing, but at this point
>> > any
>> > discussion of 2-way RP as if it's a simple binary decision is a complete
>> > waste of everyone's time.
>> >
>> >
>> > On Sat, Oct 14, 2017 at 1:31 AM, Marcel Jamin via Bitcoin-segwit2x
>> > <bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>> >>
>> >> On 14 October 2017 at 02:20, Ben Peters via Bitcoin-segwit2x
>> >> <bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>> >> > I think there is a fundamental misunderstanding about the nature of
>> >> > the
>> >> > NYA/Segwit2x endeavour. What is happening here is that an
>> >> > alternative,
>> >> > minimally modified, version of the Bitcoin code is being developed
>> >> > that
>> >> > will
>> >> > implement a change that has long been sought by the mining community
>> >> > and
>> >> > many in industry and beyond (a change that they presumably feel is
>> >> > important
>> >> > for the future success of Bitcoin and thus their respective
>> >> > investments).
>> >> >
>> >> > That candidate code will be offered to the miners and mining pools,
>> >> > who
>> >> > may
>> >> > or may not opt to apply hashing power to it. If they apply more than
>> >> > the
>> >> > threshold amount of hashing power, then that new code will
>> >> > effectively
>> >> > takeover from the previous consensus rule, and take most SPV wallets
>> >> > and
>> >> > economic activity along with it.
>> >> >
>> >> > Rather than lobbying this technical working group to “call off” their
>> >> > efforts, your time might be better spent lobbying the miners. The
>> >> > function
>> >> > of this group is to produce candidate code, thus fulfilling the
>> >> > obligations
>> >> > as set out under the NYA.
>> >>
>> >> Fair enough, but this working group is making technical decisions that
>> >> can create a lof of confusion and cause many problems for bitcoin
>> >> users.
>> >>
>> >> Much of the lobbying is targeted towards implementing strong two-way
>> >> replay protection. The reason for not implementing this protection, is
>> >> that it would reveal this project as an alternative fork of bitcoin
>> >> and is based on the assumption, that most miners will in fact employ
>> >> the client put forward by this WG and apply their hashpower to it.
>> >>
>> >> Many indicators however point towards a virtually guaranteed network
>> >> split.
>> >>
>> >> The NYA committed signers to "deployment of safe solutions that
>> >> increase bitcoin capacity". This implementation doesn't fulfill that
>> >> goal. Without strong replay protection, this will be a mess for both
>> >> sides.
>> >>
>> >> >
>> >> >
>> >> > On Oct 13, 2017, at 8:55 AM, Melvin Carvalho via Bitcoin-segwit2x
>> >> > <bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>> >> >
>> >> >
>> >> >
>> >> > On 13 October 2017 at 12:45, Melvin Carvalho
>> >> > <melvincarvalho at gmail.com>wrote:
>> >> >>
>> >> >>
>> >> >>
>> >> >> On 13 October 2017 at 12:30, Phillip Katete
>> >> >> <pekatete at hotmail.com>wrote:
>> >> >>>
>> >> >>> The disingenuity here is “painful to watch”. First you make hay of
>> >> >>> f2pool
>> >> >>> switching off NYA signaling intent THEN you rubbish signaling
>> >> >>> intent
>> >> >>> as
>> >> >>> cheap and not worthy of consideration as a metric. More worryingly,
>> >> >>> you then
>> >> >>> want to predicate the HF on miner signaling at the 80% threshold.
>> >> >>> So
>> >> >>> which
>> >> >>> is it then?
>> >> >>>
>> >> >>> Even with the EDA induced hash oscillations, I am confident hash at
>> >> >>> and
>> >> >>> post fork will mirror signaling intent.
>> >> >>
>> >> >>
>> >> >> 24h signaling fell to 79.86% [1]
>> >> >
>> >> >
>> >> > NYA signaling is now down to 77.70% in the last 24h (down from over
>> >> > 90%
>> >> > a
>> >> > day ago)
>> >> >
>> >> > https://coin.dance/blocks
>> >> >
>> >> > This does not take into account ViaBTC which may support either
>> >> > chain,
>> >> > but
>> >> > are currently signaling 100% NYA.
>> >> >
>> >> > However, much hash is mining bitcoin cash right now, and probably
>> >> > favourable
>> >> > to seg2x
>> >> >
>> >> > Additionally, you can monitor the futures market in realtime
>> >> >
>> >> > https://cryptowat.ch/bitfinex/bt2btc
>> >> >
>> >> > Currently trading at 10.6% of bitcoin (down from over 20% a day ago)
>> >> >
>> >> > You may wish to consider these metrics a source of new information
>> >> > for
>> >> > this
>> >> > project.  And / or watch them as they develop.
>> >> >
>> >> >>
>> >> >>
>> >> >> [1] https://coin.dance/blocks#thisweek
>> >> >>
>> >> >>>
>> >> >>>
>> >> >>> From: Melvin Carvalho
>> >> >>> Sent: 13 October 2017 11:11
>> >> >>> To: Phillip Katete
>> >> >>> Cc: Dr Adam Back; Emil Oldenburg; Peter Todd via Bitcoin-segwit2x
>> >> >>>
>> >> >>> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork
>> >> >>> still
>> >> >>> happening?
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> On 13 October 2017 at 11:47, Phillip Katete via Bitcoin-segwit2x
>> >> >>> <bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>> >> >>>
>> >> >>> You are barking up the wrong tree by using a “rigged” futures’
>> >> >>> price
>> >> >>> to
>> >> >>> estimate the hash supporting the upgrade at fork time. They NYA was
>> >> >>> presented as being backed by at least 80% of the network hash then
>> >> >>> and
>> >> >>> was
>> >> >>> activated / locked-in by over 90%. Since then, it has continued to
>> >> >>> receive
>> >> >>> and sustain intent signalling above the introduction threshold. It
>> >> >>> is
>> >> >>> only
>> >> >>> rational to expect the hash on fork to reflect the latter as
>> >> >>> opposed
>> >> >>> to
>> >> >>> futures’ prices.
>> >> >>>
>> >> >>> Obiter dicta: the futures’ price is more reflective of the wavering
>> >> >>> non
>> >> >>> mining, none  economic users. It goes without saying, a lot of
>> >> >>> people
>> >> >>> are
>> >> >>> going to loose a lot of money on this otherwise rigged futures’
>> >> >>> market.
>> >> >>>
>> >> >>>
>> >> >>> Markets are not always accurate, but simply a form of price
>> >> >>> discovery,
>> >> >>> I
>> >> >>> think "rigged" is perhaps a loaded term in this case and stretching
>> >> >>> things.
>> >> >>> A 12% futures market does not bode well for success, but, you never
>> >> >>> know.
>> >> >>> Since F2Pool stopped signaling NYA yesterday the signaling ratio is
>> >> >>> now
>> >> >>> about 81%, though this might have something to do with the feast
>> >> >>> and
>> >> >>> famine
>> >> >>> EDA in bitcoin cash which has just been activated.  Around 83%
>> >> >>> might
>> >> >>> be a
>> >> >>> better guess.
>> >> >>> However signaling is cheap, and many miners act in economic self
>> >> >>> interest.  Having helped run a coin for many years, I have
>> >> >>> witnessed
>> >> >>> this
>> >> >>> being the case.  There's nothing developers would like more than
>> >> >>> steady
>> >> >>> miners that stick with a coin, but sites such as coinwarz [1] all
>> >> >>> too
>> >> >>> often
>> >> >>> create spikes in hash power related to profitability.
>> >> >>> Wishing to stay on topic, I'd like to ask the following question.
>> >> >>> If
>> >> >>> signaling falls below the described 80% threshold stated above (ie
>> >> >>> one
>> >> >>> more
>> >> >>> miner stops signaling), will this this be grounds to rethink the
>> >> >>> timing of
>> >> >>> the release schedule?
>> >> >>>
>> >> >>> [1] https://www.coinwarz.com/cryptocurrency
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> From:Dr Adam Back via Bitcoin-segwit2x
>> >> >>> Sent: 13 October 2017 10:11
>> >> >>> To: Emil Oldenburg
>> >> >>> Cc: Peter Todd via Bitcoin-segwit2x
>> >> >>> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork
>> >> >>> still
>> >> >>> happening?
>> >> >>>
>> >> >>> 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
>> >> >>>
>> >> >>>
>> >> >>> _______________________________________________
>> >> >>> 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


More information about the Bitcoin-segwit2x mailing list