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

Sat Oct 14 06:24:42 UTC 2017

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