path: root/0e/7290e4665736c424d0b8e51afd6db328eea7bd

Return-Path: <bram@bittorrent.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 1BCB96C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 11 Dec 2016 01:07:09 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f171.google.com (mail-io0-f171.google.com
	[209.85.223.171])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BF3ECFD
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 11 Dec 2016 01:07:07 +0000 (UTC)
Received: by mail-io0-f171.google.com with SMTP id d9so117394054ioe.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 10 Dec 2016 17:07:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=bittorrent-com.20150623.gappssmtp.com; s=20150623;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=D31BgW1hep6XSk3x3B2d+aW9nPYfzyxZYwTQYXFCnqE=;
	b=QoRe0BPNCiG/uCwXAete7KwIzhYUcAc5Nr5j5fqAiKNbYLE3VMsXLJZGA8m3Af9blg
	xXpLNudhYwZqg1kRdVv33VqOWtIrcpn2QBbfH4yGUvMrdEUWVYz7/pUQoJ/fvYfjW8XM
	/HBnBBcNcZj3f32+tptmneOfNjUlZmnx0gqq6+PtXUZOHAaNkWZxauaurub9SLC7h41y
	hhNdRMAYHYhtkMETkVk88CVlRdGQq2emuACkDL7QYtRtWusfMcJsX4LpBfHuK5sBNaeJ
	HYj/L/qURk5B1Z9HBEr+8T5QZsV7DCXAmTYW5b+SRNkrfpZiBa85txtQOzVrhlMrVERt
	XjLQ==
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;
	bh=D31BgW1hep6XSk3x3B2d+aW9nPYfzyxZYwTQYXFCnqE=;
	b=D7HDq+x+yHb2THSjBbViX3jjUJOK79J0gyz0PGWKHdFhYC2NeZGQ5zY49p6Vrbf13y
	sU3qHDi/OVBDe3R3QI5ZX65ZUBIVyH3gUmUlrUykJil3dNGpdJLurHOwqI/5Hu96/dbM
	oPo6aay1bLqF6aSy/pHkKc9l9YljyGkzJ/2v+0ZBzPmZZvata3B2NhQhuI5tqBza26oS
	ISHT1PicESodQoCqIom9JN8nc4Kni9ZJ+Y9dO1kNWMs3GrOXE3MeJqAaWcUmpqaMymbS
	sJCp4YvA5vaIkyvsAPapR5RT56+st+P/aBIabcTV2W242OocCPp1Z4rOmCH2IgjRcVbj
	NgeQ==
X-Gm-Message-State: AKaTC02XlXkyQsX1OSMt0NmxKs6XabyMYqhrz78H/061PaQg9xsxviFBIK3/a3RHnE4ZBGZEIH20Idh877Qns3tu
X-Received: by 10.107.35.147 with SMTP id j141mr23841553ioj.41.1481418427126; 
	Sat, 10 Dec 2016 17:07:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.36.224.199 with HTTP; Sat, 10 Dec 2016 17:07:06 -0800 (PST)
In-Reply-To: <CADvTj4rLfwgzeDdYdAjUBkbCD9JcmxNPam_nuBtkM9KqGYNp=w@mail.gmail.com>
References: <CAGCNRJqdu7DMC+AMR4mYKRAYStRMKVGqbnjtEfmzcoeMij5u=A@mail.gmail.com>
	<c318f76d-0904-2e1b-453b-60179f8209bb@sky-ip.org>
	<CAGCNRJrLM2ZR9qCvuNfyr2mUk50szzHnG-crmpv_3cH=xGxYOg@mail.gmail.com>
	<CADvTj4rLfwgzeDdYdAjUBkbCD9JcmxNPam_nuBtkM9KqGYNp=w@mail.gmail.com>
From: Bram Cohen <bram@bittorrent.com>
Date: Sat, 10 Dec 2016 17:07:06 -0800
Message-ID: <CA+KqGkpws1Q9=ui8QeHpddsCSjjtbGtZK-sgAUMON6Oz+OTY0A@mail.gmail.com>
To: James Hilliard <james.hilliard1@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a114041f41cedae0543579bc6
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, 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
Subject: Re: [bitcoin-dev] Managing block size the same way we do difficulty
 (aka Block75)
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: Sun, 11 Dec 2016 01:07:09 -0000

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

Miners individually have an incentive to include every transaction they can
when they mine a block, but they also sometimes have an incentive to
collectively cooperate to reduce throughput to make more money as a group.
Under schemes where limits can be adjusted both possibilities must be taken
into account.

On Sat, Dec 10, 2016 at 4:40 PM, James Hilliard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Miners in general are naturally incentivized to always mine max size
> blocks to maximize transaction fees simply because there is very
> little marginal cost to including extra transactions(there will always
> be a transaction backlog of some sort available to mine since demand
> for block space is effectively unbounded as fees approach 0 and they
> can even mine their own transactions without any fees). This proposal
> would almost certainly cause runaway block size growth and encourage
> much more miner centralization.
>
> On Sat, Dec 10, 2016 at 6:26 PM, t. khan via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Miners 'gaming' the Block75 system -
> > There is no financial incentive for miners to attempt to game the Block=
75
> > system. Even if it were attempted and assuming the goal was to create
> bigger
> > blocks, the maximum possible increase would be 25% over the previous
> block
> > size. And, that size would only last for two weeks before readjusting
> down.
> > It would cost them more in transaction fees to stuff the network than
> they
> > could ever make up. To game the system, they'd have to game it forever
> with
> > no possibility of profit.
> >
> > Blocks would get too big -
> > Eventually, blocks would get too big, but only if bandwidth stopped
> > increasing and the cost of disk space stopped decreasing. Otherwise, th=
e
> > incremental adjustments made by Block75 (especially in combination with
> > SegWit) wouldn't break anyone's connection or result in significantly
> more
> > orphaned blocks.
> >
> > The frequent and small adjustments made by Block75 have the added
> benefit of
> > being more easily adapted to, both psychologically and technologically,
> with
> > regards to miners/node operators.
> >
> > -t.k
> >
> > On Sat, Dec 10, 2016 at 5:44 AM, s7r via bitcoin-dev
> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>
> >> t. khan via bitcoin-dev wrote:
> >> > BIP Proposal - Managing Bitcoin=E2=80=99s block size the same way we=
 do
> >> > difficulty (aka Block75)
> >> >
> >> > The every two-week adjustment of difficulty has proven to be a
> >> > reasonably effective and predictable way of managing how quickly
> blocks
> >> > are mined. Bitcoin needs a reasonably effective and predictable way =
of
> >> > managing the maximum block size.
> >> >
> >> > It=E2=80=99s clear at this point that human beings should not be inv=
olved in
> the
> >> > determination of max block size, just as they=E2=80=99re not involve=
d in
> >> > deciding the difficulty.
> >> >
> >> > Instead of setting an arbitrary max block size (1MB, 2MB, 8MB, etc.)
> or
> >> > passing the decision to miners/pool operators, the max block size
> should
> >> > be adjusted every two weeks (2016 blocks) using a system similar to
> how
> >> > difficulty is calculated.
> >> >
> >> > Put another way: let=E2=80=99s stop thinking about what the max bloc=
k size
> >> > should be and start thinking about how full we want the average bloc=
k
> to
> >> > be regardless of size. Over the last year, we=E2=80=99ve had average=
s of 75%
> or
> >> > higher, so aiming for 75% full seems reasonable, hence naming this
> >> > concept =E2=80=98Block75=E2=80=99.
> >> >
> >> > The target capacity over 2016 blocks would be 75%. If the last 2016
> >> > blocks are more than 75% full, add the difference to the max block
> size.
> >> > Like this:
> >> >
> >> > MAX_BLOCK_BASE_SIZE =3D 1000000
> >> > TARGET_CAPACITY =3D 750000
> >> > AVERAGE_OVER_CAP =3D average block size of last 2016 blocks minus
> >> > TARGET_CAPACITY
> >> >
> >> > To check if a block is valid, =E2=89=A4 (MAX_BLOCK_BASE_SIZE +
> AVERAGE_OVER_CAP)
> >> >
> >> > For example, if the last 2016 blocks are 85% full (average block is
> 850
> >> > KB), add 10% to the max block size. The new max block size would be
> >> > 1,100 KB until the next 2016 blocks are mined, then reset and
> >> > recalculate. The 1,000,000 byte limit that exists currently would
> >> > remain, but would effectively be the minimum max block size.
> >> >
> >> > Another two weeks goes by, the last 2016 blocks are again 85% full,
> but
> >> > now that means they average 935 KB out of the 1,100 KB max block siz=
e.
> >> > This is 93.5% of the 1,000,000 byte limit, so 18.5% would be added t=
o
> >> > that to make the new max block size of 1,185 KB.
> >> >
> >> > Another two weeks passes. This time, the average block is 1,050 KB.
> The
> >> > new max block size is calculated to 1,300 KB (as blocks were 105%
> full,
> >> > minus the 75% capacity target, so 30% added to max block size).
> >> >
> >> > Repeat every 2016 blocks, forever.
> >> >
> >> > If Block75 had been applied at the difficulty adjustment on November
> >> > 18th, the max block size would have been 1,080KB, as the average blo=
ck
> >> > during that period was 83% full, so 8% is added to the 1,000KB limit=
.
> >> > The current size, after the December 2nd adjustment would be 1,150K.
> >> >
> >> > Block75 would allow the max block size to grow (or shrink) in respon=
se
> >> > to transaction volume, and does so predictably, reasonably quickly,
> and
> >> > in a method that prevents wild swings in block size or transaction
> fees.
> >> > It attempts to keep blocks at 75% total capacity over each two week
> >> > period, the same way difficulty tries to keep blocks mined every ten
> >> > minutes. It also keeps blocks as small as possible.
> >> >
> >> > Thoughts?
> >> >
> >> > -t.k.
> >> >
> >>
> >> I like the idea. It is good wrt growing the max. block size
> >> automatically without human action, but the main problem (or question)
> >> is not how to grow this number, it is what number can the network
> >> handle, considering both miners and users. While disk space requiremen=
ts
> >> might not be a big problem, block propagation time is. The time requir=
ed
> >> for a block to propagate in the network (or at least to all the miners=
)
> >> is directly dependent of its size.  If blocks take too much time to
> >> propagate in the network, the orphan rate will increase in unpredictab=
le
> >> ways. For example if the internet speed in China is worse than in
> >> Europe, and miners in China have more than 50% of the hashing power,
> >> blocks mined by European miners might get orphaned.
> >>
> >> The system as described can also be gamed, by filling the network with
> >> transactions. Miners have the monetary interest to include as many
> >> transactions as possible in a block in order to collect the fees.
> >> Regardless how you think about it, there has to be a maximum block siz=
e
> >> that the network will allow as a consensus rule. Increasing it
> >> dynamically based on transaction volume will reach a point where the
> >> number got big enough that it broke things. Bitcoin, because its
> >> fundamental design, can scale by using offchain solutions.
> >>
> >>
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Miners individually have an incentive to include every tra=
nsaction they can when they mine a block, but they also sometimes have an i=
ncentive to collectively cooperate to reduce throughput to make more money =
as a group. Under schemes where limits can be adjusted both possibilities m=
ust be taken into account.</div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Sat, Dec 10, 2016 at 4:40 PM, James Hilliard via bitcoi=
n-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">Miners in general are natura=
lly incentivized to always mine max size<br>
blocks to maximize transaction fees simply because there is very<br>
little marginal cost to including extra transactions(there will always<br>
be a transaction backlog of some sort available to mine since demand<br>
for block space is effectively unbounded as fees approach 0 and they<br>
can even mine their own transactions without any fees). This proposal<br>
would almost certainly cause runaway block size growth and encourage<br>
much more miner centralization.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
On Sat, Dec 10, 2016 at 6:26 PM, t. khan via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt; Miners &#39;gaming&#39; the Block75 system -<br>
&gt; There is no financial incentive for miners to attempt to game the Bloc=
k75<br>
&gt; system. Even if it were attempted and assuming the goal was to create =
bigger<br>
&gt; blocks, the maximum possible increase would be 25% over the previous b=
lock<br>
&gt; size. And, that size would only last for two weeks before readjusting =
down.<br>
&gt; It would cost them more in transaction fees to stuff the network than =
they<br>
&gt; could ever make up. To game the system, they&#39;d have to game it for=
ever with<br>
&gt; no possibility of profit.<br>
&gt;<br>
&gt; Blocks would get too big -<br>
&gt; Eventually, blocks would get too big, but only if bandwidth stopped<br=
>
&gt; increasing and the cost of disk space stopped decreasing. Otherwise, t=
he<br>
&gt; incremental adjustments made by Block75 (especially in combination wit=
h<br>
&gt; SegWit) wouldn&#39;t break anyone&#39;s connection or result in signif=
icantly more<br>
&gt; orphaned blocks.<br>
&gt;<br>
&gt; The frequent and small adjustments made by Block75 have the added bene=
fit of<br>
&gt; being more easily adapted to, both psychologically and technologically=
, with<br>
&gt; regards to miners/node operators.<br>
&gt;<br>
&gt; -t.k<br>
&gt;<br>
&gt; On Sat, Dec 10, 2016 at 5:44 AM, s7r via bitcoin-dev<br>
&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; t. khan via bitcoin-dev wrote:<br>
&gt;&gt; &gt; BIP Proposal - Managing Bitcoin=E2=80=99s block size the same=
 way we do<br>
&gt;&gt; &gt; difficulty (aka Block75)<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; The every two-week adjustment of difficulty has proven to be =
a<br>
&gt;&gt; &gt; reasonably effective and predictable way of managing how quic=
kly blocks<br>
&gt;&gt; &gt; are mined. Bitcoin needs a reasonably effective and predictab=
le way of<br>
&gt;&gt; &gt; managing the maximum block size.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; It=E2=80=99s clear at this point that human beings should not=
 be involved in the<br>
&gt;&gt; &gt; determination of max block size, just as they=E2=80=99re not =
involved in<br>
&gt;&gt; &gt; deciding the difficulty.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Instead of setting an arbitrary max block size (1MB, 2MB, 8MB=
, etc.) or<br>
&gt;&gt; &gt; passing the decision to miners/pool operators, the max block =
size should<br>
&gt;&gt; &gt; be adjusted every two weeks (2016 blocks) using a system simi=
lar to how<br>
&gt;&gt; &gt; difficulty is calculated.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Put another way: let=E2=80=99s stop thinking about what the m=
ax block size<br>
&gt;&gt; &gt; should be and start thinking about how full we want the avera=
ge block to<br>
&gt;&gt; &gt; be regardless of size. Over the last year, we=E2=80=99ve had =
averages of 75% or<br>
&gt;&gt; &gt; higher, so aiming for 75% full seems reasonable, hence naming=
 this<br>
&gt;&gt; &gt; concept =E2=80=98Block75=E2=80=99.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; The target capacity over 2016 blocks would be 75%. If the las=
t 2016<br>
&gt;&gt; &gt; blocks are more than 75% full, add the difference to the max =
block size.<br>
&gt;&gt; &gt; Like this:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; MAX_BLOCK_BASE_SIZE =3D 1000000<br>
&gt;&gt; &gt; TARGET_CAPACITY =3D 750000<br>
&gt;&gt; &gt; AVERAGE_OVER_CAP =3D average block size of last 2016 blocks m=
inus<br>
&gt;&gt; &gt; TARGET_CAPACITY<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; To check if a block is valid, =E2=89=A4 (MAX_BLOCK_BASE_SIZE =
+ AVERAGE_OVER_CAP)<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; For example, if the last 2016 blocks are 85% full (average bl=
ock is 850<br>
&gt;&gt; &gt; KB), add 10% to the max block size. The new max block size wo=
uld be<br>
&gt;&gt; &gt; 1,100 KB until the next 2016 blocks are mined, then reset and=
<br>
&gt;&gt; &gt; recalculate. The 1,000,000 byte limit that exists currently w=
ould<br>
&gt;&gt; &gt; remain, but would effectively be the minimum max block size.<=
br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Another two weeks goes by, the last 2016 blocks are again 85%=
 full, but<br>
&gt;&gt; &gt; now that means they average 935 KB out of the 1,100 KB max bl=
ock size.<br>
&gt;&gt; &gt; This is 93.5% of the 1,000,000 byte limit, so 18.5% would be =
added to<br>
&gt;&gt; &gt; that to make the new max block size of 1,185 KB.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Another two weeks passes. This time, the average block is 1,0=
50 KB. The<br>
&gt;&gt; &gt; new max block size is calculated to 1,300 KB (as blocks were =
105% full,<br>
&gt;&gt; &gt; minus the 75% capacity target, so 30% added to max block size=
).<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Repeat every 2016 blocks, forever.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; If Block75 had been applied at the difficulty adjustment on N=
ovember<br>
&gt;&gt; &gt; 18th, the max block size would have been 1,080KB, as the aver=
age block<br>
&gt;&gt; &gt; during that period was 83% full, so 8% is added to the 1,000K=
B limit.<br>
&gt;&gt; &gt; The current size, after the December 2nd adjustment would be =
1,150K.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Block75 would allow the max block size to grow (or shrink) in=
 response<br>
&gt;&gt; &gt; to transaction volume, and does so predictably, reasonably qu=
ickly, and<br>
&gt;&gt; &gt; in a method that prevents wild swings in block size or transa=
ction fees.<br>
&gt;&gt; &gt; It attempts to keep blocks at 75% total capacity over each tw=
o week<br>
&gt;&gt; &gt; period, the same way difficulty tries to keep blocks mined ev=
ery ten<br>
&gt;&gt; &gt; minutes. It also keeps blocks as small as possible.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Thoughts?<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; -t.k.<br>
&gt;&gt; &gt;<br>
&gt;&gt;<br>
&gt;&gt; I like the idea. It is good wrt growing the max. block size<br>
&gt;&gt; automatically without human action, but the main problem (or quest=
ion)<br>
&gt;&gt; is not how to grow this number, it is what number can the network<=
br>
&gt;&gt; handle, considering both miners and users. While disk space requir=
ements<br>
&gt;&gt; might not be a big problem, block propagation time is. The time re=
quired<br>
&gt;&gt; for a block to propagate in the network (or at least to all the mi=
ners)<br>
&gt;&gt; is directly dependent of its size.=C2=A0 If blocks take too much t=
ime to<br>
&gt;&gt; propagate in the network, the orphan rate will increase in unpredi=
ctable<br>
&gt;&gt; ways. For example if the internet speed in China is worse than in<=
br>
&gt;&gt; Europe, and miners in China have more than 50% of the hashing powe=
r,<br>
&gt;&gt; blocks mined by European miners might get orphaned.<br>
&gt;&gt;<br>
&gt;&gt; The system as described can also be gamed, by filling the network =
with<br>
&gt;&gt; transactions. Miners have the monetary interest to include as many=
<br>
&gt;&gt; transactions as possible in a block in order to collect the fees.<=
br>
&gt;&gt; Regardless how you think about it, there has to be a maximum block=
 size<br>
&gt;&gt; that the network will allow as a consensus rule. Increasing it<br>
&gt;&gt; dynamically based on transaction volume will reach a point where t=
he<br>
&gt;&gt; number got big enough that it broke things. Bitcoin, because its<b=
r>
&gt;&gt; fundamental design, can scale by using offchain solutions.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.<wbr>linuxfoundation.org</a><br>
&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation=
.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
&gt;&gt;<br>
&gt;<br>
&gt;<br>
&gt; ______________________________<wbr>_________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.<wbr>linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb=
r>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
&gt;<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>
</div></div></blockquote></div><br></div>

--001a114041f41cedae0543579bc6--