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

Melvin Carvalho melvincarvalho at gmail.com
Sat Oct 14 09:08:12 UTC 2017


On 14 October 2017 at 08:58, Tony Gallippi via Bitcoin-segwit2x <
bitcoin-segwit2x at lists.linuxfoundation.org> wrote:

> If users are that particular that they want their transaction *only*
> included in a 1MB container block, and *never* in any 2MB container block,
> that is their choice.  But, even with just a 50% decrease in hashing power
> those users will start to pay very high fees for that 1MB preference and
> likely wait a very long time between blocks.
>
> The companies that signed the NYA represent probably 60%, maybe 80%, of
> all transactions on the bitcoin network today.  Blockchain and Coinbase
> together have 30 million users.  Those users are all the silent majority
> that don't comment on social media.  They just want their transaction to
> work, without preference for container size, but with a preference for a
> lower fee and less congestion.  These users have likely never run a full
> node and have no reason to.
>

Not all users would want increased capacity, if it means putting at risk
87% of the value of their asset.  I wouldn't, for example.

Increased capacity is already a common goal.  Let's do it in a way that's
safe and protects the assets of everyone.


>
> I expect at the moment of the fork, bitcoin core will still have a
> majority of nodes. But BTC1, bcoin, and many other implementations allowing
> a larger container block will have more than enough nodes to make a viable
> mesh network.
>
> We could use more implementations of bitcoin, and a defensive consensus
> amongst them.  With that, bitcoin can evolve and will be impossible to stop.
>
>

>
>
>
>
> On Sat, Oct 14, 2017 at 2:38 AM, Jacob Eliosoff via Bitcoin-segwit2x <
> bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>
>> My link included approaches that at least make it easy for users to send
>> 1x-only txs - approaches that could conceivably get deployed by 2x, and
>> thus protect 1x users.  Just repeatedly banging your head against the wall
>> with a proposal everyone can see has 0 chance at deployment (want to bet?)
>> doesn't protect users at all.  It accomplishes exactly as much for your
>> cause as sending 100 mails to this list saying "DON'T HF!"
>>
>> Anyway that's my 2c.  If you want to discuss further let's talk offline
>> or on Twitter - somewhere other than a list for plausible technical
>> proposals.
>>
>>
>> On Sat, Oct 14, 2017 at 2:24 AM, Marcel Jamin <marcel at jamin.net> 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
>>
>>
>
>
> --
> *Tony Gallippi*
> Co-founder and Executive Chairman
> BitPay, Inc.
> https://bitpay.com
>
>
> _______________________________________________
> 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/9a9ac9ee/attachment-0001.html>


More information about the Bitcoin-segwit2x mailing list