path: root/97/ee178e2279a74e04678d7e7e03b0f1f7430f69

Return-Path: <teekhan42@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id ABA0AB66
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 27 Jan 2017 18:54:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f52.google.com (mail-vk0-f52.google.com
	[209.85.213.52])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 96C7919A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 27 Jan 2017 18:54:27 +0000 (UTC)
Received: by mail-vk0-f52.google.com with SMTP id t8so181300929vke.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 27 Jan 2017 10:54:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=T2j0839hFF6EOMMERZ3NJIyxlg2N4iLV9LHkmbfUoEo=;
	b=gS/1YqD8ANREdxzRfp7E4kIizSolTAlKWiEsbxiMyMXCP2DG55gc2t64whCW6sY1Q9
	yjGKcSbbzL1Yhl3PeCWP6qmoKYISwpihqqZhjQC577QX8eSrYgTNTn7mSRMYJD6F851G
	bYvxXvh6ZPYPPxN2jMmGAmaRi17no/M2q41GpEJ2x9ATARC0+1zJM0NJdDS4FCbs2b8Q
	l2Cc5Orc2LZCHVu9EbKjoDIqrYbPoI/Bm9j4hIbrbvxGYl/98HVkK3BQPDv/uP6003vn
	/5ON59PziVBP3LR5C1irWbhGdTbe3/qb7wXc2KC5EXmOMsaZewFOFaF79juYusYkRit7
	hTmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=T2j0839hFF6EOMMERZ3NJIyxlg2N4iLV9LHkmbfUoEo=;
	b=rYWL77acQHrnXMOIfXHguP3hkhpNl9V8VR/u+ZAAmz/PpQDen0pimVh8dWf02KSMNd
	ZA7oyyXCJpJCNpKTd3r9yL/f/DgG1UbLsOXJvKp3JUVaqdVBS9axYAkOy143nzSYO91Y
	37n3jYICh1qG4OJdh7dLeuWGlfdHAYag8PdQP1WeB8r5YsW8TqG0XqUZvHgCBSwLjF31
	QwS8+pFgZE0PZ+CMDy1GnMq+SyThM2UmglSJT9n/du8/4jHO7dfTaC5LRknyygdogEKJ
	Ci6TmvaMwKgXFC5tV2PTvKWFex8k51tA19vzuPJrltRZKSYmArcpMessTB0525q6z5rK
	fILA==
X-Gm-Message-State: AIkVDXL6I4+jOGohkFeNDcSeElvz5ipYabIz2lYBIwE31XZaL/OpuRk7TSeBylitI93oqNygqzVyHqy5qp4lNQ==
X-Received: by 10.31.142.68 with SMTP id q65mr4864511vkd.83.1485543266719;
	Fri, 27 Jan 2017 10:54:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.49.77 with HTTP; Fri, 27 Jan 2017 10:54:26 -0800 (PST)
In-Reply-To: <201701270107.01092.luke@dashjr.org>
References: <201701270107.01092.luke@dashjr.org>
From: "t. khan" <teekhan42@gmail.com>
Date: Fri, 27 Jan 2017 13:54:26 -0500
Message-ID: <CAGCNRJrs6L-4ktWbNmsbhcA-4a=Pvm=hvOAaPbZur4B9Kji6rQ@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1143703ab61ebd054717fef5
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
	RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 27 Jan 2017 19:01:00 +0000
Subject: Re: [bitcoin-dev] Three hardfork-related BIPs
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Fri, 27 Jan 2017 18:54:28 -0000

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

Regarding #1, I agree with Johnson Lau and others who have responded since
then=E2=80=94this proposal is not appropriate and should not be adopted for=
 the
following reasons:

1. Miners will view it as way too little, delivered way too late. And as
soon as you say 300kb blocks, you've lost them all.

2. "Spam" - You're very fixated on this concept of spam transactions, but
the transactions that you deem as spam are legitimate, fee-paying
transactions. They're not a problem for miners. It's only a problem to you
as you've arbitrarily decided some transactions are legit and some are not.
It's an imaginary problem and we should focus on designs that solve real
problems instead.

Also, even if you changed the max size to 300kb, transactions that you (and
as far as I can tell, only you) consider spam will still be in there!
They'll just be paying a ridiculous fee along with everyone else.

3. 17% per year growth rate - This is making the assumption that the
current 1MB limit is already at the upper limit supportable by the network.
This isn't even remotely true, and starting this rate at the current limit
would cause the system to lag far behind the actual capability of the
network for no reason.

4. Nodes - Individuals have no incentive to run full nodes and we've
already passed the time where it makes any sense for them to do so.
Therefore restricting the blockchain size in an attempt to keep individuals
running nodes is futile at best and likely very damaging. Miners and
businesses using Bitcoin do have an incentive to run nodes and over the
years we've seen a migration of nodes from weak hands (individuals) to
strong hands (businesses).

Overall, this proposal would hamstring Bitcoin Core and would drive miners
towards Unlimited.

- t.k.

On Thu, Jan 26, 2017 at 8:06 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I've put together three hardfork-related BIPs. This is parallel to the
> ongoing
> research into the MMHF/SHF WIP BIP, which might still be best long-term.
>
> 1) The first is a block size limit protocol change. It also addresses thr=
ee
> criticisms of segwit: 1) segwit increases the block size limit which is
> already considered by many to be too large; 2) segwit treats pre-segwit
> transactions =E2=80=9Cunfairly=E2=80=9D by giving the witness discount on=
ly to segwit
> transactions; and 3) that spam blocks can be larger than blocks mining
> legitimate transactions. This proposal may (depending on activation date)
> initially reduce the block size limit to a more sustainable size in the
> short-
> term, and gradually increase it up over the long-term to 31 MB; it will
> also
> extend the witness discount to non-segwit transactions. Should the initia=
l
> block size limit reduction prove to be too controversial, miners can simp=
ly
> wait to activate it until closer to the point where it becomes acceptable
> and/or increases the limit. However, since the BIP includes a hardfork, t=
he
> eventual block size increase needs community consensus before it can be
> deployed. Proponents of block size increases should note that this BIP do=
es
> not interfere with another more aggressive block size increase hardfork i=
n
> the
> meantime. I believe I can immediately recommend this for adoption; howeve=
r,
> peer and community review are welcome to suggest changes.
> Text: https://github.com/luke-jr/bips/blob/bip-blksize/bip-
> blksize.mediawiki
> Code: https://github.com/bitcoin/bitcoin/compare/master...luke-
> jr:bip-blksize
> (consensus code changes only)
>
> 2) The second is a *preparatory* change, that should allow trivially
> transforming certain classes of hardforks into softforks in the future. I=
t
> essentially says that full nodes should relax their rule enforcement, aft=
er
> sufficient time that would virtually guarantee they have ceased to be
> enforcing the full set of rules anyway. This allows these relaxed rules t=
o
> be
> modified or removed in a softfork, provided the proposal to do so is
> accepted
> and implemented with enough advance notice. Attempting to implement this
> has
> proven more complicated than I originally expected, and it may make more
> sense
> for full nodes to simply stop functioning (with a user override) after th=
e
> cut-off date). In light of this, I do not yet recommend its adoption, but
> am
> posting it for review and comments only.
> Text: https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawik=
i
>
> 3) Third is an anti-replay softfork which can be used to prevent replay
> attacks whether induced by a hardfork-related chain split, or even in
> ordinary
> operation. It does this by using a new opcode (OP_CHECKBLOCKATHEIGHT) for
> the
> Bitcoin scripting system that allows construction of transactions which a=
re
> valid only on specific blockchains.
> Text: https://github.com/luke-jr/bips/blob/bip-noreplay/bip-
> noreplay.mediawiki
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Regarding #1, I agree with Johnson Lau and others who have=
 responded since then=E2=80=94this proposal is not appropriate and should n=
ot be adopted for the following reasons:<div><br></div><div>1. Miners will =
view it as way too little, delivered way too late. And as soon as you say 3=
00kb blocks, you&#39;ve lost them all.</div><div><br></div><div>2. &quot;Sp=
am&quot; - You&#39;re very fixated on this concept of spam transactions, bu=
t the transactions that you deem as spam are legitimate, fee-paying transac=
tions. They&#39;re not a problem for miners. It&#39;s only a problem to you=
 as you&#39;ve arbitrarily decided some transactions are legit and some are=
 not. It&#39;s an imaginary problem and we should focus on designs that sol=
ve real problems instead.</div><div><br></div><div>Also, even if you change=
d the max size to 300kb, transactions that you (and as far as I can tell, o=
nly you) consider spam will still be in there! They&#39;ll just be paying a=
 ridiculous fee along with everyone else.</div><div><br></div><div>3. 17% p=
er year growth rate - This is making the assumption that the current 1MB li=
mit is already at the upper limit supportable by the network. This isn&#39;=
t even remotely true, and starting this rate at the current limit would cau=
se the system to lag far behind the actual capability of the network for no=
 reason.</div><div><br></div><div>4. Nodes - Individuals have no incentive =
to run full nodes and we&#39;ve already passed the time where it makes any =
sense for them to do so. Therefore restricting the blockchain size in an at=
tempt to keep individuals running nodes is futile at best and likely very d=
amaging. Miners and businesses using Bitcoin do have an incentive to run no=
des and over the years we&#39;ve seen a migration of nodes from weak hands =
(individuals) to strong hands (businesses).</div><div><br></div><div>Overal=
l, this proposal would hamstring Bitcoin Core and would drive miners toward=
s Unlimited.</div><div><br></div><div>- t.k.</div></div><div class=3D"gmail=
_extra"><br><div class=3D"gmail_quote">On Thu, Jan 26, 2017 at 8:06 PM, Luk=
e Dashjr via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-de=
v@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfound=
ation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I&#39;ve=
 put together three hardfork-related BIPs. This is parallel to the ongoing<=
br>
research into the MMHF/SHF WIP BIP, which might still be best long-term.<br=
>
<br>
1) The first is a block size limit protocol change. It also addresses three=
<br>
criticisms of segwit: 1) segwit increases the block size limit which is<br>
already considered by many to be too large; 2) segwit treats pre-segwit<br>
transactions =E2=80=9Cunfairly=E2=80=9D by giving the witness discount only=
 to segwit<br>
transactions; and 3) that spam blocks can be larger than blocks mining<br>
legitimate transactions. This proposal may (depending on activation date)<b=
r>
initially reduce the block size limit to a more sustainable size in the sho=
rt-<br>
term, and gradually increase it up over the long-term to 31 MB; it will als=
o<br>
extend the witness discount to non-segwit transactions. Should the initial<=
br>
block size limit reduction prove to be too controversial, miners can simply=
<br>
wait to activate it until closer to the point where it becomes acceptable<b=
r>
and/or increases the limit. However, since the BIP includes a hardfork, the=
<br>
eventual block size increase needs community consensus before it can be<br>
deployed. Proponents of block size increases should note that this BIP does=
<br>
not interfere with another more aggressive block size increase hardfork in =
the<br>
meantime. I believe I can immediately recommend this for adoption; however,=
<br>
peer and community review are welcome to suggest changes.<br>
Text: <a href=3D"https://github.com/luke-jr/bips/blob/bip-blksize/bip-blksi=
ze.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/luke-=
jr/<wbr>bips/blob/bip-blksize/bip-<wbr>blksize.mediawiki</a><br>
Code: <a href=3D"https://github.com/bitcoin/bitcoin/compare/master...luke-j=
r:bip-blksize" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitc=
oin/<wbr>bitcoin/compare/master...luke-<wbr>jr:bip-blksize</a><br>
(consensus code changes only)<br>
<br>
2) The second is a *preparatory* change, that should allow trivially<br>
transforming certain classes of hardforks into softforks in the future. It<=
br>
essentially says that full nodes should relax their rule enforcement, after=
<br>
sufficient time that would virtually guarantee they have ceased to be<br>
enforcing the full set of rules anyway. This allows these relaxed rules to =
be<br>
modified or removed in a softfork, provided the proposal to do so is accept=
ed<br>
and implemented with enough advance notice. Attempting to implement this ha=
s<br>
proven more complicated than I originally expected, and it may make more se=
nse<br>
for full nodes to simply stop functioning (with a user override) after the<=
br>
cut-off date). In light of this, I do not yet recommend its adoption, but a=
m<br>
posting it for review and comments only.<br>
Text: <a href=3D"https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep=
.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/luke-jr=
/<wbr>bips/blob/bip-hfprep/bip-<wbr>hfprep.mediawiki</a><br>
<br>
3) Third is an anti-replay softfork which can be used to prevent replay<br>
attacks whether induced by a hardfork-related chain split, or even in ordin=
ary<br>
operation. It does this by using a new opcode (OP_CHECKBLOCKATHEIGHT) for t=
he<br>
Bitcoin scripting system that allows construction of transactions which are=
<br>
valid only on specific blockchains.<br>
Text: <a href=3D"https://github.com/luke-jr/bips/blob/bip-noreplay/bip-nore=
play.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/luk=
e-jr/<wbr>bips/blob/bip-noreplay/bip-<wbr>noreplay.mediawiki</a><br>
<br>
Luke<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</blockquote></div><br></div>

--001a1143703ab61ebd054717fef5--