path: root/1b/5208bf6e2a798727b10cf8f4f0a8510bae941f

Return-Path: <gubatron@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 0DC7C308
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 17 Jul 2015 21:13:47 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com
	[209.85.213.169])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 03FADB0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 17 Jul 2015 21:13:45 +0000 (UTC)
Received: by igbpg9 with SMTP id pg9so45863962igb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 17 Jul 2015 14:13:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=ecImNnJNA4YR06rjZ+Htu+uxwFCiKbugDJJ624ADP6A=;
	b=pTDWwNDJRVLsWvXerJ0NxOag7tfPA5ZRKzUsJzFtRu+PrX48LOmIJWGP4udzjwAq1T
	yqFLOToPjk3rl2I54SBHc7drQHEMbXuFRZtDtUVl1sCKwJI1WDYZ7W8ZpL32I1EcIPXO
	3JT29rn9rN7iHVH+9+/+MZvTAXFhioGACFRxpGAT6tOrgPR0SuHWb8bbovTpnKTuSJw/
	p5oYPDdSD69AzxwX46TgvvXXvTECuJt6cRHYl8vPzwDdjLRqP74p88YV6A1DTXqK+kBt
	Ex2dLuVwyWyPETpPIWoGZqZdx/ZxEpV+4a4qgQ9vMYCmMW9iTj9tox5jXBhE9EVZcZkc
	AAgA==
X-Received: by 10.107.156.203 with SMTP id f194mr20097549ioe.164.1437167625336;
	Fri, 17 Jul 2015 14:13:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.122.144 with HTTP; Fri, 17 Jul 2015 14:13:25 -0700 (PDT)
In-Reply-To: <201507172029.17056.luke@dashjr.org>
References: <CADm_WcZKoMAhYvXbFMbE+5K9HOD75YkQu8_qTW4S6YN6ZMrfjA@mail.gmail.com>
	<201507172029.17056.luke@dashjr.org>
From: Angel Leon <gubatron@gmail.com>
Date: Fri, 17 Jul 2015 17:13:25 -0400
Message-ID: <CADZB0_aSjdpLc2f1O7yJMv1O8bA0+eHsVPQcgSbRYUSNdoD45Q@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=001a1140cd00ca7cd1051b18a913
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
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: Fri, 17 Jul 2015 21:13:47 -0000

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

When blocks are found under or over the 10 minute threshold, hashing
difficulty is raised or reduced dinamically to keep a balance. This
intelligent measure has avoided us having discussions and kept a balance.

The same way you can't assume how much hashpower there will be to find the
next blocks, why can't we have a
function that adapts to the transactional volume on the blockchain, one
which allows us to grow/shrink an acceptable maximum block size. We're not
putting caps on processing, why should we put a date based cap on
transactional volume per block? You can't predict the future, but you can
look at what's happened recently to correct these limits.

Such function/filter should be able to recognize real sustained growth in
transactional volume and let us adjust the maximum accepted blocksize to
allow for the organic growth that will come due to real activity from
things like distributed market-places, decentralized bitcoin based services
(and all the things the community dreams about and might be building
already), truly decentralized technological breakthroughs that geniunely
need to use the blockchain. <Going the off-chain way only leads to
centralization and personal/corporate agendas, which to me goes against the
Bitcoin ethos>

It should be able to adapt fast enough so that we don't have episodes where
people need to wait 4 hours to days for transactions to get on the
blockchain and be confirmed. I believe proposals that include "every
100,000 blocks" are out of touch with reality, the blocksize needs to adapt
the same way blockdifficulty already adapts to growth or lack of hashing
power.

I'm not a statistician/mathematician, but I'm sure if we propose the
parameters that need to be considered for a realistic blocksize that
reflects the needs of the Bitcoin network users, there's plenty of
crypto/statistician/mathematician brain power to propose such filtering
function here.

Things that could be considered:
- median number of transactions per block (between 6 to 12 hours, you
should be able to adjust to a real shopping sprint for instance, or huge
pop band/artist decides to sell concert tickets on Bitcoin)
- median fees offered per transaction (can we detect spammers)
- median blocksizes
- median size per transaction
- number of new addresses signing off transactions, number of addresses
we've already seen in the blockchain before (are these spammers creating
lots of new addresses to move around the same outputs, is there an
efficient way to detect the likelyhood of a transaction being spam? Bayes?
No clue, no mathematician)
- median velocity between which an address receives an input and sends it
to another one?
- more things I've no knowledge of since I'm not familiar with the details,
but could immediatly come to mind to the experts.

Mining Centralization is already happening due to its competitive nature,
we don't complain or try to force hashing limits, we shouldn't do the same
for storage. There will be no shortage of blockchain mirrors, and those
interested in running full nodes, will surely find a way to do so.

Angel

http://twitter.com/gubatron

On Fri, Jul 17, 2015 at 4:29 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Friday, July 17, 2015 3:55:19 PM Jeff Garzik via bitcoin-dev wrote:
> > BIP PR: https://github.com/bitcoin/bips/pull/173
>
> I'm concerned that miners are prematurely bumping their soft limit to 1 MB
> lately. The only reason block size limit lifting is remotely reasonable is
> if
> we can trust miners to at the very least keep their soft limits set at a
> manageable size, but this assumption appears to already be failing in
> practice.
>
> We are unlikely to approach 1 MB of actual volume by November, so I would
> prefer to see the activation date on this moved later - maybe November
> 2016,
> if not 2017. It would also be an improvement to try to follow reasonably-
> expected bandwidth increases, so 15% (1.15 MB) rather than doubling.
> Doubling
> in only a few months seems to be far from a "conservative" increase.
>
> If we can get some kind of commitment from miners not to move their soft
> limits beyond 1 MB until some future-agreed-on point, maybe the BIP is
> acceptable as-is.
>
> On Friday, July 17, 2015 4:12:05 PM Tier Nolan via bitcoin-dev wrote:
> > It establishes a precedent for hard forks not to require a vote though.
>
> Hardforks are not something where voting makes sense. They need consensus
> among /nodes/, not majority among /miners/. No hardfork has ever had such a
> vote.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>When blocks are found under or over the 10 minute thr=
eshold, hashing difficulty is raised or reduced dinamically to keep a balan=
ce. This intelligent measure has avoided us having discussions and kept a b=
alance.</div><div><br></div><div>The same way you can&#39;t assume how much=
 hashpower there will be to find the next blocks, why can&#39;t we have a</=
div><div>function that adapts to the transactional volume on the blockchain=
, one which allows us to grow/shrink an acceptable maximum block size. We&#=
39;re not putting caps on processing, why should we put a date based cap on=
 transactional volume per block? You can&#39;t predict the future, but you =
can look at what&#39;s happened recently to correct these limits.</div><div=
><br></div><div>Such function/filter should be able to recognize real susta=
ined growth in transactional volume and let us adjust the maximum accepted =
blocksize to allow for the organic growth that will come due to real activi=
ty from things like distributed market-places, decentralized bitcoin based =
services (and all the things the community dreams about and might be buildi=
ng already), truly decentralized technological breakthroughs that geniunely=
 need to use the blockchain. &lt;Going the off-chain way only leads to cent=
ralization and personal/corporate agendas, which to me goes against the Bit=
coin ethos&gt;=C2=A0</div><div><br></div><div>It should be able to adapt fa=
st enough so that we don&#39;t have episodes where people need to wait 4 ho=
urs to days for transactions to get on the blockchain and be confirmed. I b=
elieve proposals that include &quot;every 100,000 blocks&quot; are out of t=
ouch with reality, the blocksize needs to adapt the same way blockdifficult=
y already adapts to growth or lack of hashing power.</div><div><br></div><d=
iv>I&#39;m not a statistician/mathematician, but I&#39;m sure if we propose=
 the parameters that need to be considered for a realistic blocksize that r=
eflects the needs of the Bitcoin network users, there&#39;s plenty of crypt=
o/statistician/mathematician brain power to propose such filtering function=
 here.</div><div><br></div><div>Things that could be considered:</div><div>=
- median number of transactions per block (between 6 to 12 hours, you shoul=
d be able to adjust to a real shopping sprint for instance, or huge pop ban=
d/artist decides to sell concert tickets on Bitcoin)</div><div>- median fee=
s offered per transaction (can we detect spammers)</div><div>- median block=
sizes</div><div>- median size per transaction</div><div>- number of new add=
resses signing off transactions, number of addresses we&#39;ve already seen=
 in the blockchain before (are these spammers creating lots of new addresse=
s to move around the same outputs, is there an efficient way to detect the =
likelyhood of a transaction being spam? Bayes? No clue, no mathematician)</=
div><div>- median velocity between which an address receives an input and s=
ends it to another one?</div><div>- more things I&#39;ve no knowledge of si=
nce I&#39;m not familiar with the details, but could immediatly come to min=
d to the experts.</div><div><br></div><div>Mining Centralization is already=
 happening due to its competitive nature, we don&#39;t complain or try to f=
orce hashing limits, we shouldn&#39;t do the same for storage. There will b=
e no shortage of blockchain mirrors, and those interested in running full n=
odes, will surely find a way to do so.=C2=A0<br><br>Angel</div></div><div c=
lass=3D"gmail_extra"><br clear=3D"all"><div><div class=3D"gmail_signature">=
<a href=3D"http://twitter.com/gubatron" target=3D"_blank">http://twitter.co=
m/gubatron</a><br></div></div>
<br><div class=3D"gmail_quote">On Fri, Jul 17, 2015 at 4:29 PM, Luke Dashjr=
 via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.=
linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.or=
g</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Friday, July 1=
7, 2015 3:55:19 PM Jeff Garzik via bitcoin-dev wrote:<br>
&gt; BIP PR: <a href=3D"https://github.com/bitcoin/bips/pull/173" rel=3D"no=
referrer" target=3D"_blank">https://github.com/bitcoin/bips/pull/173</a><br=
>
<br>
I&#39;m concerned that miners are prematurely bumping their soft limit to 1=
 MB<br>
lately. The only reason block size limit lifting is remotely reasonable is =
if<br>
we can trust miners to at the very least keep their soft limits set at a<br=
>
manageable size, but this assumption appears to already be failing in<br>
practice.<br>
<br>
We are unlikely to approach 1 MB of actual volume by November, so I would<b=
r>
prefer to see the activation date on this moved later - maybe November 2016=
,<br>
if not 2017. It would also be an improvement to try to follow reasonably-<b=
r>
expected bandwidth increases, so 15% (1.15 MB) rather than doubling. Doubli=
ng<br>
in only a few months seems to be far from a &quot;conservative&quot; increa=
se.<br>
<br>
If we can get some kind of commitment from miners not to move their soft<br=
>
limits beyond 1 MB until some future-agreed-on point, maybe the BIP is<br>
acceptable as-is.<br>
<br>
On Friday, July 17, 2015 4:12:05 PM Tier Nolan via bitcoin-dev wrote:<br>
&gt; It establishes a precedent for hard forks not to require a vote though=
.<br>
<br>
Hardforks are not something where voting makes sense. They need consensus<b=
r>
among /nodes/, not majority among /miners/. No hardfork has ever had such a=
<br>
vote.<br>
<br>
Luke<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>
</blockquote></div><br></div>

--001a1140cd00ca7cd1051b18a913--