<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 >
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 &
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 > 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"><<a
href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org"
target="_blank" moz-do-not-send="true">bitcoin-segwit2x@lists.linuxfoundation.org</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class="">> We do not know what the views of the hashing
power are; hashing power is free<br>
> 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>
> 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>
> The Ethereum chain was left with even less hashing
power<br>
> 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 <<a
href="mailto:pete@petertodd.org"
moz-do-not-send="true">pete@petertodd.org</a>>
wrote:<br>
> On Tue, Jul 25, 2017 at 09:02:25AM -0700, Jared Lee
Richardson wrote:<br>
>> Right now between signalling and signatories,
btc1 has ~95% of the<br>
>> hashpower. ~5% of the hashpower is not enough
to be viable without a<br>
>> hardfork, in which case it would be more
appropriate and less damaging for<br>
><br>
> The signalling has been done by mining *pools*, not
hashing power.<br>
><br>
> We do not know what the views of the hashing power
are; hashing power is free<br>
> to move from one pool to another, and can do so in
a matter of minutes.<br>
><br>
> Equally, even if Bitcoin was left with just 5% of
the hashing power, and B2X<br>
> with 95%, that situation still allows for coins to
be bought and sold, with an<br>
> unknown outcome. The Ethereum chain was left with
even less hashing power<br>
> immediately after the bailout fork - nearly 0% -
but hashing power rapidly<br>
> moved from the bailout chain back to the Ethereum
chain in response to market<br>
> demand.<br>
><br>
> --<br>
> <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>