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

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. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20171014/d80990c8/attachment-0001.html>