<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>As one of the signers of the New York Agreement, Bitcoin.com is
      strongly against replay protection for the November 2xHF.</p>
    <p>If replay protection is added and it's similar to Bitcoin Cash,
      the New York Agreement will die and the hard fork will never
      actually happen. This is the latest tactic from the Core camp to
      kill the hard fork.</p>
    <p>The problem is relayed transactions is not new and has been well
      known by everyone who signed the agreement. The spirit of the
      agreement was to get a super majority support for the hard fork,
      enough to bring non-signers over to the hard forked chain as the
      legacy chain would quickly be abandoned. The difficulty of the
      bitcoin network is so high right now that if 90% hard forks, the
      legacy chain will in practice be unusable. Exchanges can only list
      activate and usable chains.<br>
    </p>
    <p>There is a reason Luke-Jr and a few other Core supporters are
      preparing for a PoW change, because they know this.</p>
    <p>Adding replay protection that breaks all wallets is a no go.
      Gavin's op-return method is good enough, and Core can easily add a
      soft fork to Core that works in a similar way. The replay
      protection responsibility falls on to the minority chain, not the
      majority.<br>
    </p>
    <p><br>
    </p>
    <pre class="moz-signature" cols="72">Emil Oldenburg, CTO
<a class="moz-txt-link-abbreviated" href="mailto:Emil@bitcoin.com">Emil@bitcoin.com</a>
Visit the all new <a class="moz-txt-link-freetext" href="https://bitcoin.com">https://bitcoin.com</a>
Wechat: emilold
Telegram: emilold</pre>
    <div class="moz-cite-prefix">On 2017年08月22日 03:14, Gabriel Kurman
      via Bitcoin-segwit2x wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CABnzwL+tmDpxRhOGWKg_hHFcKcw1+uTiFLhHnFRRSM+KNZ4kuw@mail.gmail.com">
      <div dir="ltr">
        <div>Dear all,</div>
        <div><br>
        </div>
        <div>
          <div style="font-size:12.8px">Sergio, Diego and myself have
            been discussing the potential implications of the November
            2xHF and its lack of replay protection upon all the recent
            information from Bcash and the reaction of the ecosystem.
            Below you will find a summary of our thoughts.</div>
          <div style="font-size:12.8px"><br>
          </div>
        </div>
        <div><br>
        </div>
        <div>New info:</div>
        <div>
          <ul style="color:rgb(80,0,80);font-size:12.8px">
            <li style="margin-left:15px">The Bcash fork was successful
              and not contentious </li>
            <li style="margin-left:15px">It was received as "free money"
              by Bitcoiners and the users seem to be cool with ViaBTC</li>
            <li style="margin-left:15px">All exchanges/wallets are
              working to make the coins available</li>
            <li style="margin-left:15px">No major attacks have been
              registered and now both chains seem to be working without
              permanent contentious attacks from the competing miners</li>
            <li style="margin-left:15px">Bcash plans to launch an
              aggressive pipeline of innovation Schors, Drivechain,
              Emergent consensus, LN and merge-mining to promote its
              use/price</li>
            <li style="margin-left:15px">The ecosystem has now more
              development diversification/decentralizati<wbr>on</li>
            <li style="margin-left:15px">Price of BTC + BCash &gt;
              Original BTC </li>
            <li style="margin-left:15px"><b>REPLAY PROTECTION (RP) was
                key for all the points addressed before.</b></li>
            <li style="margin-left:15px">Bcash proved that is fairly
              easy and quick to add RP</li>
            <li style="margin-left:15px">Past evidence shows that the
              name seems to stay with Devs/Repo (happened with ETH and
              Bcash)</li>
          </ul>
          <div style="color:rgb(80,0,80);font-size:12.8px">Why are we
            worried:</div>
          <div style="color:rgb(80,0,80);font-size:12.8px">
            <ul>
              <li style="margin-left:15px">The current version of the
                NYA does not include RP<br>
              </li>
              <li style="margin-left:15px">Without RP, at the HF there
                will be a lot of uncertainty and confusion. Users &amp;
                exchanges will be forced to halt their
                transactions/trading <span style="font-size:12.8px">until
                  there is a clear outcome of the fork which we think
                  may take up to 2 weeks</span>.</li>
              <li style="margin-left:15px">Users willing to transact
                will be loosing their tokens in some of the chains</li>
              <ul>
                <li style="margin-left:15px">The NYA will probably be
                  perceived as an attack on the users</li>
                <li style="margin-left:15px">Users will be disappointed
                  for not having their tokens duplicated</li>
                <li style="margin-left:15px">An endless war will be
                  started between both groups, minimizing the chances of
                  independent Core developers contributing to the btc1
                  repo</li>
              </ul>
              <li style="margin-left:15px">Even without RP it is hard to
                predict how the ecosystem will call the 2x token</li>
              <li style="margin-left:15px"><b>It is unclear how many of
                  the original signatories of the NYA still support it
                  today given the new info and the no RP</b></li>
            </ul>
            <div>Why btc1 should include RP:</div>
          </div>
          <div style="color:rgb(80,0,80);font-size:12.8px">
            <ul>
              <li style="margin-left:15px">Having RP on the NYA would
                bring the following benefits:</li>
              <ul>
                <li style="margin-left:15px">Trading will not be stopped
                  (reducing the ETH flippening risk or BTC price
                  collapse)</li>
                <li style="margin-left:15px">Bitcoiners will love it for
                  duplicating their tokens</li>
                <ul>
                  <li style="margin-left:15px">Market will expect Price
                    of BTC + BTC2x &gt; Original BTC </li>
                </ul>
                <li style="margin-left:15px">Both teams will compete in
                  terms of innovation, security, services to users and
                  lower fees</li>
                <li style="margin-left:15px">There will not be a
                  significant incentive for miners/holders to attack the
                  competitive chain.</li>
                <li style="margin-left:15px">It will be easier for devs
                  to contribute to both teams/repos</li>
                <li style="margin-left:15px">Eventually the most
                  successful blockchain will be called Bitcoin in the
                  long term</li>
              </ul>
              <li>Potential liabilities (?): All exchanges (specially
                those publicly signing the NYA) should discuss with
                their technical and legal teams how they are going to
                make the Core tokens available once their users claim
                them<br>
              </li>
            </ul>
          </div>
          <div style="color:rgb(80,0,80);font-size:12.8px"><br>
          </div>
          <div style="color:rgb(80,0,80);font-size:12.8px">Given that
            very few details has been discussed with the NYA signatories
            back in May, it is very important to clarify whether having
            REPLAY PROTECTION is open to discussion or not, so all
            signatories can confirm/reject their support to the NYA.</div>
          <div style="color:rgb(80,0,80);font-size:12.8px"><br>
          </div>
          <div style="color:rgb(80,0,80);font-size:12.8px"><br>
          </div>
          <div style="color:rgb(80,0,80);font-size:12.8px">Our goal has
            always been to try to keep the ecosystem together protecting
            the network effect, however if a separation is inevitable,
            at least it should be done in a way that protects users
            interests at all costs<span style="font-size:12.8px">.</span></div>
          <div style="color:rgb(80,0,80);font-size:12.8px"><span
              style="font-size:12.8px"><br>
            </span></div>
          <div style="color:rgb(80,0,80);font-size:12.8px">If the btc1
            group agrees to include REPLAY PROTECTION, we would be happy
            to allocate resources to collaborate in the development or
            testing of it.</div>
        </div>
        <div style="color:rgb(80,0,80);font-size:12.8px"><br>
        </div>
        <div style="color:rgb(80,0,80);font-size:12.8px"><br>
        </div>
        <div style="color:rgb(80,0,80);font-size:12.8px"><br>
        </div>
        <div><br>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">2017-07-25 19:35 GMT-03:00 Jared Lee
          Richardson via Bitcoin-segwit2x <span dir="ltr">&lt;<a
              href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org"
              target="_blank" moz-do-not-send="true">bitcoin-segwit2x@lists.linuxfoundation.org</a>&gt;</span>:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex"><span
              class="">&gt; We do not know what the views of the hashing
              power are; hashing power is free<br>
              &gt; to move from one pool to another, and can do so in a
              matter of minutes.<br>
              <br>
            </span>That's fallacious logic.  If individual miners indeed
            did not wish to<br>
            support segwit2x, continuing to mine to a pool that signed
            support<br>
            over a month ago and has been signaling support for weeks
            wouldn't<br>
            make any sense - their inaction only makes support for
            segwit2x seem<br>
            STRONGER.  The fact that miners have not done the thing you
            are<br>
            claiming that miners will do taking a matter of minutes is
            strong<br>
            evidence that you're speculating without any evidence.<br>
            <br>
            Can you provide evidence that indicates miners are currently
            mining to<br>
            a pool who'se agenda they do not support?<br>
            <br>
            Because if not, I can provide evidence showing the
            opposite.  Slush,<br>
            the only pool not signed/signaling /NYA/, was ~5% of the
            hashrate 1<br>
            month ago and is now 2.5% of the hashrate.  If what you are
            saying is<br>
            true that number would be going up, not down.  Please
            provide evidence<br>
            to support your claims.<br>
            <span class=""><br>
              &gt; that situation still allows for coins to be bought
              and sold<br>
              <br>
            </span>Where?<br>
            <br>
            No exchange has stated they will support the legacy chain as
            bitcoin<br>
            instead of the most-work chain.  Moreover, 5% of the
            hashrate is not<br>
            only insufficient to process anything approaching our
            current volume<br>
            of transactions (even with segwit!), it is also a highly
            unstable<br>
            equilibrium - Given the extreme lack of blocks, many neutral
            users<br>
            will abandon it immediately, and any miners without strong
            convictions<br>
            will abandon it within hours to protect their investments,
            making the<br>
            slow blocks problem even worse.<br>
            <br>
            Even worse than that, the only significant pool I can find
            that isn't<br>
            signaling /NYA/ has historically always allowed its' miners
            to vote,<br>
            and doesn't own many miners to back its own convictions. 
            That 5%<br>
            hashrate itself may be split, weakening what was already
            nowhere near<br>
            enough hashrate for viability.<br>
            <span class=""><br>
              &gt;  The Ethereum chain was left with even less hashing
              power<br>
              &gt; immediately after the bailout fork - nearly 0% - but
              hashing power rapidly<br>
              <br>
            </span>You mean like minutes afterwards?  Because that
            wasn't true days<br>
            afterwards.  Regardless, Ethereum is not a good comparison,
            it<br>
            continuously adjusts difficulty and wouldn't be stuck for 6+
            months,<br>
            and miners are already applying the new rules and indicating
            they are<br>
            running the HF code.<br>
            <br>
            Please provide evidence of your claims.<br>
            <br>
            Jared<br>
            <div class="HOEnZb">
              <div class="h5"><br>
                On Tue, Jul 25, 2017 at 3:03 PM, Peter Todd &lt;<a
                  href="mailto:pete@petertodd.org"
                  moz-do-not-send="true">pete@petertodd.org</a>&gt;
                wrote:<br>
                &gt; On Tue, Jul 25, 2017 at 09:02:25AM -0700, Jared Lee
                Richardson wrote:<br>
                &gt;&gt; Right now between signalling and signatories,
                btc1 has ~95% of the<br>
                &gt;&gt; hashpower.  ~5% of the hashpower is not enough
                to be viable without a<br>
                &gt;&gt; hardfork, in which case it would be more
                appropriate and less damaging for<br>
                &gt;<br>
                &gt; The signalling has been done by mining *pools*, not
                hashing power.<br>
                &gt;<br>
                &gt; We do not know what the views of the hashing power
                are; hashing power is free<br>
                &gt; to move from one pool to another, and can do so in
                a matter of minutes.<br>
                &gt;<br>
                &gt; Equally, even if Bitcoin was left with just 5% of
                the hashing power, and B2X<br>
                &gt; with 95%, that situation still allows for coins to
                be bought and sold, with an<br>
                &gt; unknown outcome. The Ethereum chain was left with
                even less hashing power<br>
                &gt; immediately after the bailout fork - nearly 0% -
                but hashing power rapidly<br>
                &gt; moved from the bailout chain back to the Ethereum
                chain in response to market<br>
                &gt; demand.<br>
                &gt;<br>
                &gt; --<br>
                &gt; <a href="https://petertodd.org" rel="noreferrer"
                  target="_blank" moz-do-not-send="true">https://petertodd.org</a>
                'peter'[:-1]@<a href="http://petertodd.org"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">petertodd.org</a><br>
              </div>
            </div>
            <div class="HOEnZb">
              <div class="h5">______________________________<wbr>_________________<br>
                Bitcoin-segwit2x mailing list<br>
                <a
                  href="mailto:Bitcoin-segwit2x@lists.linuxfoundation.org"
                  moz-do-not-send="true">Bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a><br>
                <a
href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>segwit2x</a><br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
        <br clear="all">
        <div><br>
        </div>
        -- <br>
        <div class="gmail_signature" data-smartmail="gmail_signature">
          <div dir="ltr">Gabriel Kurman
            <div>Co-Founder</div>
            <div><br>
            </div>
            <div><a href="http://www.RSK.co" target="_blank"
                moz-do-not-send="true">www.RSK.co</a></div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Bitcoin-segwit2x mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-segwit2x@lists.linuxfoundation.org">Bitcoin-segwit2x@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>