path: root/d1/e9a498bc8ac1a9043aa19c6a86e98cbec32863

Return-Path: <samson.mow@btcc.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 81ADDD0E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  9 Feb 2016 05:12:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yk0-f174.google.com (mail-yk0-f174.google.com
	[209.85.160.174])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 11CCF101
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  9 Feb 2016 05:12:17 +0000 (UTC)
Received: by mail-yk0-f174.google.com with SMTP id r207so96554176ykd.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 08 Feb 2016 21:12:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=btcc-com.20150623.gappssmtp.com; s=20150623;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=N/HzZaPSJYHwcR0m+QIALCZmYTOP38SnkD3Qv12k09w=;
	b=fqwkRcNUkol05aiaRT6nkKDpuQg6CAU1leEjBHUuCu1FXJ0XDcG/YmDF7FTeobAcYo
	5eGbo7k+OsEXTwCFn2Yzh6dS+KJUIwR/xNiDno33dNiFqpW1SciyH7zAx3Nun34aYH1J
	aMHHnkEvCdH34nZYEALoXTOsa6NtFzjRoEj7iv5BM14zPVxwFn/gS5UqLyyYagpKBCJ1
	vwDewe0HBQDkNzXMjNk/D4DB6l408DV2CI+mgRRZCPD8jvf4wCAVCbOZHjzsh+HxleU3
	gPoEXnfLoAomEyy6R0+XcvuAghdSdbNgr9oZu8OTibARQ6SuCGCcsIOnM0fczIaES95F
	P8eQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=N/HzZaPSJYHwcR0m+QIALCZmYTOP38SnkD3Qv12k09w=;
	b=IBuKOxfuP/teVZ/y/t1QJjL53NKt1Z8UztySMmMaIrmJiwR0BRRTdgtlp+MExJheem
	Vdc7EVakK7m+gQEL+icBcG4m9VXmKvDw3SVwUNmsCgOqhY13B9i9LD91r9H2kMdZhe/Q
	VElcUz6yRmzX8kSyk6dko1Td1HwKJ0jt9mfhuoNc/kbbuKXogc0RV2tKbJgDf55mlCC7
	oy3ggszP+0d4aeMod/ltQ/yNwMq+7G8Ql8uLL201vKDRLXnHgoX/e2OU5hyWFNvyOhX6
	J/lUBPf4vrBLgWwNR08GD7k3QM/ZsTKvOozMjnbhJU6JL59YSRNCUeeIrQ97iFjQRNwX
	GuPQ==
X-Gm-Message-State: AG10YOTZdyjzfzhip485hfSlv13XDSKMcivbqeYn5NOelQ+Gx0uZY1FS8M08Ld9ULPNNihGlcxt9n73HuCOw/gQh
X-Received: by 10.37.90.87 with SMTP id o84mr15834267ybb.16.1454994736368;
	Mon, 08 Feb 2016 21:12:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.216.7 with HTTP; Mon, 8 Feb 2016 21:11:56 -0800 (PST)
In-Reply-To: <20160206211158.GA14053@muck>
References: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com>
	<201602060012.26728.luke@dashjr.org>
	<CABm2gDrns0+eZdLyNk=tDNbnMsC1tT1MfEY93cJf1V_8TPjmLA@mail.gmail.com>
	<CABsx9T2LuMZciXpMiY24+rPzhj1VT6j=HJ5STtnQmnfnA_XFUw@mail.gmail.com>
	<CALqxMTGu1EtVxRYTxLBpE-0zWH59dnQa1zst9p9vdmbCckBjtQ@mail.gmail.com>
	<CABsx9T2AUwDdz3JowpQYeusDgCBwfNFCDz0Kfut9ffT6gSaGeQ@mail.gmail.com>
	<20160206211158.GA14053@muck>
From: Samson Mow <samson.mow@btcc.com>
Date: Tue, 9 Feb 2016 13:11:56 +0800
Message-ID: <CAKzt8a9=Yfon8jNDbgDUDi3VSr9_rhsO=Oc0wjSqxXsYVeD9tQ@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a114268886984ad052b4f5c57
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 09 Feb 2016 06:29:41 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2
	megabytes
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Feb 2016 05:12:19 -0000

--001a114268886984ad052b4f5c57
Content-Type: text/plain; charset=UTF-8

Gavin, please don't quote that list on the Classic website. It's horribly
inaccurate and misleading to the general public.

> That testing is happening by the exchange, library, wallet, etc providers
> themselves. There is a list on the Classic home page:
>
> https://bitcoinclassic.com/

I know for a fact that most companies you list there have no intention to
run Classic, much less test it. You should not mix support for 2MB with
support for Classic, or if people say they welcome a fork, to mean they
support Classic.

On Sun, Feb 7, 2016 at 5:11 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sat, Feb 06, 2016 at 12:45:14PM -0500, Gavin Andresen via bitcoin-dev
> wrote:
> > On Sat, Feb 6, 2016 at 12:01 PM, Adam Back <adam@cypherspace.org> wrote:
> >
> > >
> > > It would probably be a good idea to have a security considerations
> > > section
> >
> >
> > Containing what?  I'm not aware of any security considerations that are
> any
> > different from any other consensus rules change.
>
> I covered the security considerations unique to hard-forks on my blog:
>
> https://petertodd.org/2016/soft-forks-are-safer-than-hard-forks
>
> > > , also, is there a list of which exchange, library, wallet,
> > > pool, stats server, hardware etc you have tested this change against?
> > >
> >
> > That testing is happening by the exchange, library, wallet, etc providers
> > themselves. There is a list on the Classic home page:
> >
> > https://bitcoinclassic.com/
>
> How do we know any of this testing is actually being performed? I don't
> currently know of any concrete testing actually done.
>
> > > Do you have a rollback plan in the event the hard-fork triggers via
> > > false voting as seemed to be prevalent during XT?  (Or rollback just
> > > as contingency if something unforseen goes wrong).
> > >
> >
> > The only voting in this BIP is done by the miners, and that cannot be
> faked.
>
> Are you unaware of Not Bitcoin XT?
>
> https://bitcointalk.org/index.php?topic=1154520.0
>
> > I can't imagine any even-remotely-likely sequence of events that would
> > require a rollback, can you be more specific about what you are
> imagining?
> > Miners suddenly getting cold feet?
>
> See above.
>
> Also, as the two coins are separate currencies and can easily trade
> against each other in a 75%/25% split, it would be easy for the price to
> diverge and hashing power to move.
>
> In fact, I've been asked multiple times now by exchanges and other
> players in this ecosystem for technical advice on how to split coins
> across the chains effectively (easily done with nLockTime). Notably, the
> exchanges who have asked me this - who hold customer funds on their
> behalf - have informed me that their legal advice was that the
> post-hard-fork coins are legally speaking separate currencies, and
> customers must be given the opportunity to transact in them separately
> if they choose too.  Obviously, with a 75%/25% split, while block times
> on the other chain will be slower, the chain is still quite useful and
> nearly as secure as the main chain against 51% attack; why I personally
> have suggested a 99% threshold:
>
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012309.html
>
> (remember that the threshold can always be soft-forked down)
>
> It's also notable that millions of dollars of Bitcoin are voting agsast
> the fork on the proof-of-stake voting site Bitcoinocracy.com While
> obviously not comprehensive, the fact that a relatively obscure site
> like it can achieve participation like that, even without an easy to use
> user friendly interface.
>
> > > How do you plan to monitor and manage security through the hard-fork?
> > >
> >
> > I don't plan to monitor or manage anything; the Bitcoin network is
> > self-monitoring and self-managing. Services like statoshi.info will do
> the
> > monitoring, and miners and people and businesses will manage the network,
> > as they do every day.
>
> Please provide details on exactly how that's going to happen.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> 000000000000000008320874843f282f554aa2436290642fcfa81e5a01d78698
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--001a114268886984ad052b4f5c57
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Gavin, please don&#39;t quote that list on the Classi=
c website. It&#39;s horribly inaccurate and misleading to the general publi=
c.</div><div><br></div><div><span style=3D"color:rgb(80,0,80);font-size:12.=
8px">&gt; That testing is happening by the exchange, library, wallet, etc p=
roviders</span><br style=3D"color:rgb(80,0,80);font-size:12.8px"><span styl=
e=3D"color:rgb(80,0,80);font-size:12.8px">&gt; themselves. There is a list =
on the Classic home page:</span><br style=3D"color:rgb(80,0,80);font-size:1=
2.8px"><span style=3D"color:rgb(80,0,80);font-size:12.8px">&gt;</span><br s=
tyle=3D"color:rgb(80,0,80);font-size:12.8px"><span style=3D"color:rgb(80,0,=
80);font-size:12.8px">&gt;=C2=A0</span><a href=3D"https://bitcoinclassic.co=
m/" rel=3D"noreferrer" target=3D"_blank" style=3D"font-size:12.8px">https:/=
/bitcoinclassic.com/</a><br></div><div><br></div><div>I know for a fact tha=
t most companies you list there have no intention to run Classic, much less=
 test it. You should not mix support for 2MB with support for Classic, or i=
f people say they welcome a fork, to mean they support Classic.</div></div>=
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun, Feb 7, 20=
16 at 5:11 AM, Peter Todd via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"=
mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev=
@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><span class=3D"">On Sat, Feb 06, 2016 at 12:45:14PM -0500, Gavin An=
dresen via bitcoin-dev wrote:<br>
&gt; On Sat, Feb 6, 2016 at 12:01 PM, Adam Back &lt;<a href=3D"mailto:adam@=
cypherspace.org">adam@cypherspace.org</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; It would probably be a good idea to have a security consideration=
s<br>
&gt; &gt; section<br>
&gt;<br>
&gt;<br>
&gt; Containing what?=C2=A0 I&#39;m not aware of any security consideration=
s that are any<br>
&gt; different from any other consensus rules change.<br>
<br>
</span>I covered the security considerations unique to hard-forks on my blo=
g:<br>
<br>
<a href=3D"https://petertodd.org/2016/soft-forks-are-safer-than-hard-forks"=
 rel=3D"noreferrer" target=3D"_blank">https://petertodd.org/2016/soft-forks=
-are-safer-than-hard-forks</a><br>
<span class=3D""><br>
&gt; &gt; , also, is there a list of which exchange, library, wallet,<br>
&gt; &gt; pool, stats server, hardware etc you have tested this change agai=
nst?<br>
&gt; &gt;<br>
&gt;<br>
&gt; That testing is happening by the exchange, library, wallet, etc provid=
ers<br>
&gt; themselves. There is a list on the Classic home page:<br>
&gt;<br>
&gt; <a href=3D"https://bitcoinclassic.com/" rel=3D"noreferrer" target=3D"_=
blank">https://bitcoinclassic.com/</a><br>
<br>
</span>How do we know any of this testing is actually being performed? I do=
n&#39;t<br>
currently know of any concrete testing actually done.<br>
<span class=3D""><br>
&gt; &gt; Do you have a rollback plan in the event the hard-fork triggers v=
ia<br>
&gt; &gt; false voting as seemed to be prevalent during XT?=C2=A0 (Or rollb=
ack just<br>
&gt; &gt; as contingency if something unforseen goes wrong).<br>
&gt; &gt;<br>
&gt;<br>
&gt; The only voting in this BIP is done by the miners, and that cannot be =
faked.<br>
<br>
</span>Are you unaware of Not Bitcoin XT?<br>
<br>
<a href=3D"https://bitcointalk.org/index.php?topic=3D1154520.0" rel=3D"nore=
ferrer" target=3D"_blank">https://bitcointalk.org/index.php?topic=3D1154520=
.0</a><br>
<span class=3D""><br>
&gt; I can&#39;t imagine any even-remotely-likely sequence of events that w=
ould<br>
&gt; require a rollback, can you be more specific about what you are imagin=
ing?<br>
&gt; Miners suddenly getting cold feet?<br>
<br>
</span>See above.<br>
<br>
Also, as the two coins are separate currencies and can easily trade<br>
against each other in a 75%/25% split, it would be easy for the price to<br=
>
diverge and hashing power to move.<br>
<br>
In fact, I&#39;ve been asked multiple times now by exchanges and other<br>
players in this ecosystem for technical advice on how to split coins<br>
across the chains effectively (easily done with nLockTime). Notably, the<br=
>
exchanges who have asked me this - who hold customer funds on their<br>
behalf - have informed me that their legal advice was that the<br>
post-hard-fork coins are legally speaking separate currencies, and<br>
customers must be given the opportunity to transact in them separately<br>
if they choose too.=C2=A0 Obviously, with a 75%/25% split, while block time=
s<br>
on the other chain will be slower, the chain is still quite useful and<br>
nearly as secure as the main chain against 51% attack; why I personally<br>
have suggested a 99% threshold:<br>
<br>
<a href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-Janu=
ary/012309.html" rel=3D"noreferrer" target=3D"_blank">http://lists.linuxfou=
ndation.org/pipermail/bitcoin-dev/2016-January/012309.html</a><br>
<br>
(remember that the threshold can always be soft-forked down)<br>
<br>
It&#39;s also notable that millions of dollars of Bitcoin are voting agsast=
<br>
the fork on the proof-of-stake voting site Bitcoinocracy.com While<br>
obviously not comprehensive, the fact that a relatively obscure site<br>
like it can achieve participation like that, even without an easy to use<br=
>
user friendly interface.<br>
<span class=3D""><br>
&gt; &gt; How do you plan to monitor and manage security through the hard-f=
ork?<br>
&gt; &gt;<br>
&gt;<br>
&gt; I don&#39;t plan to monitor or manage anything; the Bitcoin network is=
<br>
&gt; self-monitoring and self-managing. Services like <a href=3D"http://sta=
toshi.info" rel=3D"noreferrer" target=3D"_blank">statoshi.info</a> will do =
the<br>
&gt; monitoring, and miners and people and businesses will manage the netwo=
rk,<br>
&gt; as they do every day.<br>
<br>
</span>Please provide details on exactly how that&#39;s going to happen.<br=
>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org"=
 rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
000000000000000008320874843f282f554aa2436290642fcfa81e5a01d78698<br>
</font></span><br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>

--001a114268886984ad052b4f5c57--