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

Jacob Eliosoff jacob.eliosoff at gmail.com
Sat Oct 14 05:53:58 UTC 2017


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
<https://github.com/btc1/bitcoin/issues/34#issuecomment-329251611>, 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20171014/f64f923f/attachment-0001.html>


More information about the Bitcoin-segwit2x mailing list