<div dir="ltr">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!"<br><br>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.<div><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 14, 2017 at 2:24 AM, Marcel Jamin <span dir="ltr"><<a href="mailto:marcel@jamin.net" target="_blank">marcel@jamin.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I wouldn't consider any opt-in approach as "strong" replay protection.<br>
If this WG as NACKed strong two way replay protection, then it's not a<br>
safe upgrade path und thus not an implementation honoring the NYA.<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
On 14 October 2017 at 07:53, Jacob Eliosoff <<a href="mailto:jacob.eliosoff@gmail.com">jacob.eliosoff@gmail.com</a>> wrote:<br>
> Can I ask that anyone advocating 2-way replay protection (which I also<br>
> support) be specific about how they propose it be done? No disrespect<br>
> meant, but BCH-style RP, that would require old wallets to upgrade, has been<br>
> proposed and emphatically NACKed here umpteen times: it is just unrealistic<br>
> to think this project would adopt it at this stage. There are other 2-way<br>
> RP approaches that I still believe are worth pursuing, but at this point any<br>
> discussion of 2-way RP as if it's a simple binary decision is a complete<br>
> waste of everyone's time.<br>
><br>
><br>
> On Sat, Oct 14, 2017 at 1:31 AM, Marcel Jamin via Bitcoin-segwit2x<br>
> <<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org">bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a>> wrote:<br>
>><br>
>> On 14 October 2017 at 02:20, Ben Peters via Bitcoin-segwit2x<br>
>> <<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org">bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a>> wrote:<br>
>> > I think there is a fundamental misunderstanding about the nature of the<br>
>> > NYA/Segwit2x endeavour. What is happening here is that an alternative,<br>
>> > minimally modified, version of the Bitcoin code is being developed that<br>
>> > will<br>
>> > implement a change that has long been sought by the mining community and<br>
>> > many in industry and beyond (a change that they presumably feel is<br>
>> > important<br>
>> > for the future success of Bitcoin and thus their respective<br>
>> > investments).<br>
>> ><br>
>> > That candidate code will be offered to the miners and mining pools, who<br>
>> > may<br>
>> > or may not opt to apply hashing power to it. If they apply more than the<br>
>> > threshold amount of hashing power, then that new code will effectively<br>
>> > takeover from the previous consensus rule, and take most SPV wallets and<br>
>> > economic activity along with it.<br>
>> ><br>
>> > Rather than lobbying this technical working group to “call off” their<br>
>> > efforts, your time might be better spent lobbying the miners. The<br>
>> > function<br>
>> > of this group is to produce candidate code, thus fulfilling the<br>
>> > obligations<br>
>> > as set out under the NYA.<br>
>><br>
>> Fair enough, but this working group is making technical decisions that<br>
>> can create a lof of confusion and cause many problems for bitcoin<br>
>> users.<br>
>><br>
>> Much of the lobbying is targeted towards implementing strong two-way<br>
>> replay protection. The reason for not implementing this protection, is<br>
>> that it would reveal this project as an alternative fork of bitcoin<br>
>> and is based on the assumption, that most miners will in fact employ<br>
>> the client put forward by this WG and apply their hashpower to it.<br>
>><br>
>> Many indicators however point towards a virtually guaranteed network<br>
>> split.<br>
>><br>
>> The NYA committed signers to "deployment of safe solutions that<br>
>> increase bitcoin capacity". This implementation doesn't fulfill that<br>
>> goal. Without strong replay protection, this will be a mess for both<br>
>> sides.<br>
>><br>
>> ><br>
>> ><br>
>> > On Oct 13, 2017, at 8:55 AM, Melvin Carvalho via Bitcoin-segwit2x<br>
>> > <<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org">bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a>> wrote:<br>
>> ><br>
>> ><br>
>> ><br>
>> > On 13 October 2017 at 12:45, Melvin Carvalho<br>
>> > <<a href="mailto:melvincarvalho@gmail.com">melvincarvalho@gmail.com</a>><wbr>wrote:<br>
>> >><br>
>> >><br>
>> >><br>
>> >> On 13 October 2017 at 12:30, Phillip Katete<br>
>> >> <<a href="mailto:pekatete@hotmail.com">pekatete@hotmail.com</a>>wrote:<br>
>> >>><br>
>> >>> The disingenuity here is “painful to watch”. First you make hay of<br>
>> >>> f2pool<br>
>> >>> switching off NYA signaling intent THEN you rubbish signaling intent<br>
>> >>> as<br>
>> >>> cheap and not worthy of consideration as a metric. More worryingly,<br>
>> >>> you then<br>
>> >>> want to predicate the HF on miner signaling at the 80% threshold. So<br>
>> >>> which<br>
>> >>> is it then?<br>
>> >>><br>
>> >>> Even with the EDA induced hash oscillations, I am confident hash at<br>
>> >>> and<br>
>> >>> post fork will mirror signaling intent.<br>
>> >><br>
>> >><br>
>> >> 24h signaling fell to 79.86% [1]<br>
>> ><br>
>> ><br>
>> > NYA signaling is now down to 77.70% in the last 24h (down from over 90%<br>
>> > a<br>
>> > day ago)<br>
>> ><br>
>> > <a href="https://coin.dance/blocks" rel="noreferrer" target="_blank">https://coin.dance/blocks</a><br>
>> ><br>
>> > This does not take into account ViaBTC which may support either chain,<br>
>> > but<br>
>> > are currently signaling 100% NYA.<br>
>> ><br>
>> > However, much hash is mining bitcoin cash right now, and probably<br>
>> > favourable<br>
>> > to seg2x<br>
>> ><br>
>> > Additionally, you can monitor the futures market in realtime<br>
>> ><br>
>> > <a href="https://cryptowat.ch/bitfinex/bt2btc" rel="noreferrer" target="_blank">https://cryptowat.ch/bitfinex/<wbr>bt2btc</a><br>
>> ><br>
>> > Currently trading at 10.6% of bitcoin (down from over 20% a day ago)<br>
>> ><br>
>> > You may wish to consider these metrics a source of new information for<br>
>> > this<br>
>> > project. And / or watch them as they develop.<br>
>> ><br>
>> >><br>
>> >><br>
>> >> [1] <a href="https://coin.dance/blocks#thisweek" rel="noreferrer" target="_blank">https://coin.dance/blocks#<wbr>thisweek</a><br>
>> >><br>
>> >>><br>
>> >>><br>
>> >>> From: Melvin Carvalho<br>
>> >>> Sent: 13 October 2017 11:11<br>
>> >>> To: Phillip Katete<br>
>> >>> Cc: Dr Adam Back; Emil Oldenburg; Peter Todd via Bitcoin-segwit2x<br>
>> >>><br>
>> >>> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still<br>
>> >>> happening?<br>
>> >>><br>
>> >>><br>
>> >>><br>
>> >>><br>
>> >>> On 13 October 2017 at 11:47, Phillip Katete via Bitcoin-segwit2x<br>
>> >>> <<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org">bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a>> wrote:<br>
>> >>><br>
>> >>> You are barking up the wrong tree by using a “rigged” futures’ price<br>
>> >>> to<br>
>> >>> estimate the hash supporting the upgrade at fork time. They NYA was<br>
>> >>> presented as being backed by at least 80% of the network hash then and<br>
>> >>> was<br>
>> >>> activated / locked-in by over 90%. Since then, it has continued to<br>
>> >>> receive<br>
>> >>> and sustain intent signalling above the introduction threshold. It is<br>
>> >>> only<br>
>> >>> rational to expect the hash on fork to reflect the latter as opposed<br>
>> >>> to<br>
>> >>> futures’ prices.<br>
>> >>><br>
>> >>> Obiter dicta: the futures’ price is more reflective of the wavering<br>
>> >>> non<br>
>> >>> mining, none economic users. It goes without saying, a lot of people<br>
>> >>> are<br>
>> >>> going to loose a lot of money on this otherwise rigged futures’<br>
>> >>> market.<br>
>> >>><br>
>> >>><br>
>> >>> Markets are not always accurate, but simply a form of price discovery,<br>
>> >>> I<br>
>> >>> think "rigged" is perhaps a loaded term in this case and stretching<br>
>> >>> things.<br>
>> >>> A 12% futures market does not bode well for success, but, you never<br>
>> >>> know.<br>
>> >>> Since F2Pool stopped signaling NYA yesterday the signaling ratio is<br>
>> >>> now<br>
>> >>> about 81%, though this might have something to do with the feast and<br>
>> >>> famine<br>
>> >>> EDA in bitcoin cash which has just been activated. Around 83% might<br>
>> >>> be a<br>
>> >>> better guess.<br>
>> >>> However signaling is cheap, and many miners act in economic self<br>
>> >>> interest. Having helped run a coin for many years, I have witnessed<br>
>> >>> this<br>
>> >>> being the case. There's nothing developers would like more than<br>
>> >>> steady<br>
>> >>> miners that stick with a coin, but sites such as coinwarz [1] all too<br>
>> >>> often<br>
>> >>> create spikes in hash power related to profitability.<br>
>> >>> Wishing to stay on topic, I'd like to ask the following question. If<br>
>> >>> signaling falls below the described 80% threshold stated above (ie one<br>
>> >>> more<br>
>> >>> miner stops signaling), will this this be grounds to rethink the<br>
>> >>> timing of<br>
>> >>> the release schedule?<br>
>> >>><br>
>> >>> [1] <a href="https://www.coinwarz.com/cryptocurrency" rel="noreferrer" target="_blank">https://www.coinwarz.com/<wbr>cryptocurrency</a><br>
>> >>><br>
>> >>><br>
>> >>><br>
>> >>> From:Dr Adam Back via Bitcoin-segwit2x<br>
>> >>> Sent: 13 October 2017 10:11<br>
>> >>> To: Emil Oldenburg<br>
>> >>> Cc: Peter Todd via Bitcoin-segwit2x<br>
>> >>> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still<br>
>> >>> happening?<br>
>> >>><br>
>> >>> The futures price is 1/3 of 40% so yes actually < 40% hashrate is<br>
>> >>> quite<br>
>> >>> likely.<br>
>> >>><br>
>> >>><br>
>> >>><br>
>> >>><br>
>> >>> <a href="https://www.cryptonator.com/rates/BT2-BTC?utm_referrer=https%3a%2f%2fwww.google.com%2f" rel="noreferrer" target="_blank">https://www.cryptonator.com/<wbr>rates/BT2-BTC?utm_referrer=<wbr>https%3a%2f%2fwww.google.com%<wbr>2f</a><br>
>> >>><br>
>> >>> Nodes should upgrade because code changes are being made and it's not<br>
>> >>> a good idea to run pre-production code on the live network. Do you<br>
>> >>> recall when the company you work for lost bitcoin by running<br>
>> >>> pre-release fork code before on the pool?<br>
>> >>><br>
>> >>> Is anyone running BTC1 head in production? Protecting how much value.<br>
>> >>> Reminder this is a public list.<br>
>> >>><br>
>> >>> Adam<br>
>> >>><br>
>> >>> On Fri, Oct 13, 2017 at 11:01 AM, Emil Oldenburg via Bitcoin-segwit2x<br>
>> >>> <<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org">bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a>> wrote:<br>
>> >>> > The hardfork part is already locked in and is not subject to change.<br>
>> >>> > Many<br>
>> >>> > btc1 nodes are already deployed and they should not and don't need<br>
>> >>> > to<br>
>> >>> > update. The only thing left is a potential extra softfork for opt-in<br>
>> >>> > replay<br>
>> >>> > protection. Only the miners need this softfork.<br>
>> >>> ><br>
>> >>> > What makes you think the hardfork will have less than 40% hashpower?<br>
>> >>> ><br>
>> >>> ><br>
>> >>> > Emil Oldenburg, CTO<br>
>> >>> > <a href="mailto:Emil@bitcoin.com">Emil@bitcoin.com</a><br>
>> >>> > Visit the all new <a href="https://bitcoin.com" rel="noreferrer" target="_blank">https://bitcoin.com</a><br>
>> >>> > Wechat: emilold<br>
>> >>> > Telegram: emilold<br>
>> >>> ><br>
>> >>> > On 2017<br>
>> >>> 年10月13日17:31, Peter BitcoinReminder.com wrote:<br>
>> >>><br>
>> >>> ><br>
>> >>> > Thats not a reason, the BTC1 sourcecode is still in development<br>
>> >>> > (f.e.<br>
>> >>> > replay<br>
>> >>> > protection was reverted just 1-2 days ago?) - so the argument „it<br>
>> >>> > can’t<br>
>> >>> > be<br>
>> >>> > called off“ is just wrong.<br>
>> >>> ><br>
>> >>> > So wouldn’t it make sense to add a minimum required hashrate for the<br>
>> >>> > HF<br>
>> >>> > to<br>
>> >>> > lock in? You are really going to fork off with f.e. 40 % hashpower?<br>
>> >>> ><br>
>> >>> ><br>
>> >>> > Am 13.10.2017 um 03:42 schrieb Emil Oldenburg via Bitcoin-segwit2x<br>
>> >>> > <<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org">bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a>>:<br>
>> >>> ><br>
>> >>> > If we try to be technical here. The HF is already activated, is<br>
>> >>> > estimated to<br>
>> >>> > trigger in 36 days, and can't be "called off". Nor is there any<br>
>> >>> > logic<br>
>> >>> > to<br>
>> >>> > delay it if hashrate deflects. That's the rules of the btc1 client.<br>
>> >>> ><br>
>> >>> ><br>
>> >>> > Emil Oldenburg, CTO<br>
>> >>> > <a href="mailto:Emil@bitcoin.com">Emil@bitcoin.com</a><br>
>> >>> > Visit the all new <a href="https://bitcoin.com" rel="noreferrer" target="_blank">https://bitcoin.com</a><br>
>> >>> > Wechat: emilold<br>
>> >>> > Telegram: emilold<br>
>> >>> ><br>
>> >>> > On 2017<br>
>> >>> 年10月13日05:31, John Heathco via Bitcoin-segwit2x wrote:<br>
>> >>><br>
>> >>> ><br>
>> >>> > I don't believe there is an explicitly stated hashpower in which the<br>
>> >>> > fork<br>
>> >>> > would be "called off", but I would assume it is much lower than what<br>
>> >>> > is<br>
>> >>> > currently signaling, even if we make the (unwise) assumption that<br>
>> >>> > F2Pool<br>
>> >>> > would not contribute to mining 2x whatsoever.<br>
>> >>> ><br>
>> >>> ><br>
>> >>> ><br>
>> >>> > On Thu, Oct 12, 2017 at 12:57 PM Peter BitcoinReminder.com via<br>
>> >>> > Bitcoin-segwit2x <<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org">bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a>> wrote:<br>
>> >>> >><br>
>> >>> >> I’m not Peter Todd, we just share the same (nice) firstname.<br>
>> >>> >><br>
>> >>> >> I still didn’t get an answer what the minimum amount of hashpower<br>
>> >>> >> is<br>
>> >>> >> required, before the fork is getting delayed?<br>
>> >>> >> We have to plan time for the whole security measures etc, so I<br>
>> >>> >> think<br>
>> >>> >> it’s<br>
>> >>> >> reasonable to get more information about this?<br>
>> >>> >><br>
>> >>> >><br>
>> >>> >> Am 12.10.2017 um 21:53 schrieb bitPico <<a href="mailto:bitpico@icloud.com">bitpico@icloud.com</a>>:<br>
>> >>> >><br>
>> >>> >> Without you knowing why they stopped signaling this is FUD and<br>
>> >>> >> off-topic<br>
>> >>> >> for this list. Please instead let F2Pool state their own opinion<br>
>> >>> >> here<br>
>> >>> >> since<br>
>> >>> >> yours doesn’t count. If you think your opinion does count then show<br>
>> >>> >> us<br>
>> >>> >> your<br>
>> >>> >> blocks that your pool has produced; until then you are simply an<br>
>> >>> >> end-user<br>
>> >>> >> and still you are off-topic for this list. If you need ELI5 for how<br>
>> >>> >> this<br>
>> >>> >> list works please let us know and we can help you Peter Todd.<br>
>> >>> >><br>
>> >>> >> Have a groovy day!<br>
>> >>> >><br>
>> >>> >> On Oct 12, 2017, at 8:49 AM, Peter BitcoinReminder.com via<br>
>> >>> >> Bitcoin-segwit2x <<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org">bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a>><br>
>> >>> >> wrote:<br>
>> >>> >><br>
>> >>> >> Since F2Pool stopped signaling for the NYA[1] and slush also mines<br>
>> >>> >> mostly<br>
>> >>> >> non-NYA blocks, are you still going to fork off in November -<br>
>> >>> >> splitting the<br>
>> >>> >> chain intentionally?<br>
>> >>> >><br>
>> >>> >> —<br>
>> >>> >> [1] <a href="https://imgur.com/LgYdFKw" rel="noreferrer" target="_blank">https://imgur.com/LgYdFKw</a><br>
</div></div></blockquote></div><br></div></div></div>