path: root/b4/d45d464cb6abc1757aba17b6dcf73a5dd574c7

Return-Path: <bitcoin@upalc.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id BD1D7EFF
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 27 Aug 2015 15:09:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com
	[209.85.213.176])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 27D6B188
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 27 Aug 2015 15:09:19 +0000 (UTC)
Received: by ignq3 with SMTP id q3so11092396ign.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 27 Aug 2015 08:09:18 -0700 (PDT)
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:date
	:message-id:subject:from:to:cc:content-type;
	bh=oZ4bsAnKFqSJF+d556qd1mIPzKBsodwtDl/amFbiQJI=;
	b=iOniR5LdSewYn0W9EhxqGP5tU958M3iY+HvauB6ysadqNMsB7SW812lbFmt92NwGXy
	Z17IS7F851cE0TC9q+DwJR6U5neHkrzzdKqKH/SufJv6SMjXLk5IteaimUrRMlf7XTIK
	8oB51cKZGfKpLg1URGY/ltKUN360Aoq4gSB02LJQ9DLX9BA/7G/8BINiHneuVvy+8eSN
	AHwKL5su5mwRsLnQitIaTLphOlx6+/4O2s/l8SGw7wPEGqeE+/XMj84elEffy+3HxsWg
	9KvDNSbYN5Eb9a6DQXR0FZGLiO9qS9AfKw81dRPKrfo/9MLZS92LyrgpyWjVYB9a5uI2
	aceA==
X-Gm-Message-State: ALoCoQke5q41FLAW4+SQyf5d9DxCxBcl0vew1k1bYNMctqTQrn13ZQm/+XM9Uw+BQ84rg7LFXT4q
MIME-Version: 1.0
X-Received: by 10.50.79.202 with SMTP id l10mr9817407igx.7.1440688158341; Thu,
	27 Aug 2015 08:09:18 -0700 (PDT)
Received: by 10.107.18.155 with HTTP; Thu, 27 Aug 2015 08:09:18 -0700 (PDT)
X-Originating-IP: [115.187.37.59]
In-Reply-To: <CAFzgq-x9GBbqARyhMgfSPc=wYeBgzXy4VUQ0D76GC+TCAxWDuA@mail.gmail.com>
References: <CAED3CWipF8u5g3LUrqfyHxvEk4Lu+d12ZOJZnoBUw6iZZOg-ZQ@mail.gmail.com>
	<CAFzgq-x9GBbqARyhMgfSPc=wYeBgzXy4VUQ0D76GC+TCAxWDuA@mail.gmail.com>
Date: Thu, 27 Aug 2015 20:39:18 +0530
Message-ID: <CAED3CWh0Yi87mdfwoaOJsuTv5TM77+bVP2B_quWbS8RJUFLJRw@mail.gmail.com>
From: Upal Chakraborty <bitcoin@upalc.com>
To: Chun Wang <1240902@gmail.com>
Content-Type: multipart/alternative; boundary=089e0122aaeee92291051e4c5970
X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_WEB 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 <bitcoin-dev@lists.linuxfoundation.org>, greg@xiph.org
Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
 [BIP 1xx - Draft]
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: Thu, 27 Aug 2015 15:09:30 -0000

--089e0122aaeee92291051e4c5970
Content-Type: text/plain; charset=UTF-8

Proposal 1 does not deal with Tx fee. Proposal 2 does. According to
proposal 2, miners wont be able to increase or decrease Max Block Size only
by manipulating Tx fee. They have to manipulate...
i. Tx fee of ~4000 blocks.
ii. Block size of ~4000 blocks.

I never proposed *next block collects Tx fee from previous block*. Not sure
what you mean here!

On Tue, Aug 25, 2015 at 2:49 PM, Chun Wang <1240902@gmail.com> wrote:

> Proposal 1 looks good, but tx fee collected can be manipulated by
> miners. I like the idea next block collect the tx fee from previous
> block.
>
> On Tue, Aug 25, 2015 at 5:07 PM, Upal Chakraborty via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Github:
> >
> https://github.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlockSize.mediawiki
> >
> > <pre>
> >   BIP: 1xx
> >   Title: Dynamically Controlled Bitcoin Block Size Max Cap
> >   Author: Upal Chakraborty <bitcoin@upalc.com>
> >   Status: Draft
> >   Type: Standards Track
> >   Created: 2015-08-24
> > </pre>
> >
> > ==Abstract==
> >
> > This BIP proposes replacing the fixed one megabyte maximum block size
> with a
> > dynamically controlled maximum block size that may increase or decrease
> with
> > difficulty change depending on various network factors. I have two
> proposals
> > regarding this...
> >
> > i. Depending only on previous block size calculation.
> >
> > ii. Depending on previous block size calculation and previous Tx fee
> > collected by miners.
> >
> > ==Motivation==
> >
> > With increased adoption, transaction volume on bitcoin network is bound
> to
> > grow. If the one megabyte max cap is not changed to a flexible one which
> > changes itself with changing network demand, then adoption will hamper
> and
> > bitcoin's growth may choke up. Following graph shows the change in
> average
> > block size since inception...
> >
> >
> https://blockchain.info/charts/avg-block-size?timespan=all&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=
> >
> > ==Specification==
> >
> > ===Proposal 1 : Depending only on previous block size calculation===
> >
> >   If more than 50% of block's size, found in the first 2000 of the last
> > difficulty period, is more than 90% MaxBlockSize
> >       Double MaxBlockSize
> >   Else if more than 90% of block's size, found in the first 2000 of the
> last
> > difficulty period, is less than 50% MaxBlockSize
> >       Half MaxBlockSize
> >   Else
> >       Keep the same MaxBlockSize
> >
> > ===Proposal 2 : Depending on previous block size calculation and
> previous Tx
> > fee collected by miners===
> >
> >   TotalBlockSizeInLastButOneDifficulty = Sum of all Block size of first
> 2008
> > blocks in last 2 difficulty period
> >   TotalBlockSizeInLastDifficulty = Sum of all Block size of second 2008
> > blocks in last 2 difficulty period (This actually includes 8 blocks from
> > last but one difficulty)
> >
> >   TotalTxFeeInLastButOneDifficulty = Sum of all Tx fees of first 2008
> blocks
> > in last 2 difficulty period
> >   TotalTxFeeInLastDifficulty = Sum of all Tx fees of second 2008 blocks
> in
> > last 2 difficulty period (This actually includes 8 blocks from last but
> one
> > difficulty)
> >
> >   If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016
> >
> > 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty >
> > TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty >
> > TotalBlockSizeInLastButOneDifficulty) )
> >       MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize /
> > TotalBlockSizeInLastButOneDifficulty
> >   Else If ( ( (Sum of first 4016 block size in last 2 difficulty
> > period)/4016 < 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty <
> > TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty <
> > TotalBlockSizeInLastButOneDifficulty) )
> >       MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize /
> > TotalBlockSizeInLastButOneDifficulty
> >   Else
> >       Keep the same MaxBlockSize
> >
> > ==Rationale==
> >
> > These two proposals have been derived after discussion on
> > [https://bitcointalk.org/index.php?topic=1154536.0 BitcoinTalk] and
> > [
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010285.html
> > bitcoin-dev mailing list]. The original idea and its evolution in the
> light
> > of various arguements can be found [http://upalc.com/maxblocksize.php
> here].
> >
> > ===Proposal 1 : Depending only on previous block size calculation===
> >
> > This solution is derived directly from the indication of the problem. If
> > transaction volume increases, then we will naturally see bigger blocks.
> On
> > the contrary, if there are not enough transaction volume, but maximum
> block
> > size is high, then only few blocks may sweep the mempool. Hence, if block
> > size is itself taken into consideration, then maximum block size can most
> > rationally be derived. Moreover, this solution not only increases, but
> also
> > decreases the maximum block size, just like difficulty.
> >
> > ===Proposal 2 : Depending on previous block size calculation and
> previous Tx
> > fee collected by miners===
> >
> > This solution takes care of stable mining subsidy. It will not increase
> > maximum block size, if Tx fee collection is not increasing and thereby
> > creating a Tx fee pressure on the market. On the other hand, though the
> > block size max cap is dynamically controlled, it is very difficult to
> game
> > by any party because the increase or decrease of block size max cap will
> > take place in the same ratio of average block size increase or decrease.
> >
> > ==Compatibility==
> >
> > This is a hard-forking change to the Bitcoin protocol; anybody running
> code
> > that fully validates blocks must upgrade before the activation time or
> they
> > will risk rejecting a chain containing larger-than-one-megabyte blocks.
> >
> > ==Other solutions considered==
> >
> > [http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf Making
> > Decentralized Economic Policy] - by Jeff Garzik
> >
> > [https://bitcointalk.org/index.php?topic=1078521.0 Elastic block cap
> with
> > rollover penalties] - by Meni Rosenfeld
> >
> > [https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki Increase
> > maximum block size] - by Gavin Andresen
> >
> > [https://gist.github.com/sipa/c65665fc360ca7a176a6 Block size following
> > technological growth] - by Pieter Wuille
> >
> > [https://lightning.network/lightning-network-paper.pdf The Bitcoin
> Lightning
> > Network: Scalable Off-Chain Instant Payments] - by Joseph Poon & Thaddeus
> > Dryja
> >
> > ==Deployment==
> >
> > If consensus is achieved, deployment can be made at a future block
> number at
> > which difficulty will change.
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>

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

<div dir=3D"ltr"><span style=3D"font-size:12.8000001907349px">Proposal 1 do=
es not deal with Tx fee. Proposal 2 does. According to proposal 2, miners w=
ont be able to increase or decrease Max Block Size only by manipulating Tx =
fee. They have to manipulate...</span><div style=3D"font-size:12.8000001907=
349px">i. Tx fee of ~4000 blocks.</div><div style=3D"font-size:12.800000190=
7349px">ii. Block size of ~4000 blocks.</div><div style=3D"font-size:12.800=
0001907349px"><br></div><div style=3D"font-size:12.8000001907349px">I never=
 proposed=C2=A0<b>next block collects Tx fee from previous block</b>. Not s=
ure what you mean here!</div></div><div class=3D"gmail_extra"><br><div clas=
s=3D"gmail_quote">On Tue, Aug 25, 2015 at 2:49 PM, Chun Wang <span dir=3D"l=
tr">&lt;<a href=3D"mailto:1240902@gmail.com" target=3D"_blank">1240902@gmai=
l.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Proposal 1 lo=
oks good, but tx fee collected can be manipulated by<br>
miners. I like the idea next block collect the tx fee from previous<br>
block.<br>
<div><div class=3D"h5"><br>
On Tue, Aug 25, 2015 at 5:07 PM, Upal Chakraborty via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.linuxfoundation.org</a>&gt; wrote:<br>
&gt; Github:<br>
&gt; <a href=3D"https://github.com/UpalChakraborty/bips/blob/master/BIP-Dyn=
amicMaxBlockSize.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://gi=
thub.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlockSize.mediawiki=
</a><br>
&gt;<br>
&gt; &lt;pre&gt;<br>
&gt;=C2=A0 =C2=A0BIP: 1xx<br>
&gt;=C2=A0 =C2=A0Title: Dynamically Controlled Bitcoin Block Size Max Cap<b=
r>
&gt;=C2=A0 =C2=A0Author: Upal Chakraborty &lt;<a href=3D"mailto:bitcoin@upa=
lc.com">bitcoin@upalc.com</a>&gt;<br>
&gt;=C2=A0 =C2=A0Status: Draft<br>
&gt;=C2=A0 =C2=A0Type: Standards Track<br>
&gt;=C2=A0 =C2=A0Created: 2015-08-24<br>
&gt; &lt;/pre&gt;<br>
&gt;<br>
&gt; =3D=3DAbstract=3D=3D<br>
&gt;<br>
&gt; This BIP proposes replacing the fixed one megabyte maximum block size =
with a<br>
&gt; dynamically controlled maximum block size that may increase or decreas=
e with<br>
&gt; difficulty change depending on various network factors. I have two pro=
posals<br>
&gt; regarding this...<br>
&gt;<br>
&gt; i. Depending only on previous block size calculation.<br>
&gt;<br>
&gt; ii. Depending on previous block size calculation and previous Tx fee<b=
r>
&gt; collected by miners.<br>
&gt;<br>
&gt; =3D=3DMotivation=3D=3D<br>
&gt;<br>
&gt; With increased adoption, transaction volume on bitcoin network is boun=
d to<br>
&gt; grow. If the one megabyte max cap is not changed to a flexible one whi=
ch<br>
&gt; changes itself with changing network demand, then adoption will hamper=
 and<br>
&gt; bitcoin&#39;s growth may choke up. Following graph shows the change in=
 average<br>
&gt; block size since inception...<br>
&gt;<br>
&gt; <a href=3D"https://blockchain.info/charts/avg-block-size?timespan=3Dal=
l&amp;showDataPoints=3Dfalse&amp;daysAverageString=3D1&amp;show_header=3Dtr=
ue&amp;scale=3D0&amp;address=3D" rel=3D"noreferrer" target=3D"_blank">https=
://blockchain.info/charts/avg-block-size?timespan=3Dall&amp;showDataPoints=
=3Dfalse&amp;daysAverageString=3D1&amp;show_header=3Dtrue&amp;scale=3D0&amp=
;address=3D</a><br>
&gt;<br>
&gt; =3D=3DSpecification=3D=3D<br>
&gt;<br>
&gt; =3D=3D=3DProposal 1 : Depending only on previous block size calculatio=
n=3D=3D=3D<br>
&gt;<br>
&gt;=C2=A0 =C2=A0If more than 50% of block&#39;s size, found in the first 2=
000 of the last<br>
&gt; difficulty period, is more than 90% MaxBlockSize<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0Double MaxBlockSize<br>
&gt;=C2=A0 =C2=A0Else if more than 90% of block&#39;s size, found in the fi=
rst 2000 of the last<br>
&gt; difficulty period, is less than 50% MaxBlockSize<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0Half MaxBlockSize<br>
&gt;=C2=A0 =C2=A0Else<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0Keep the same MaxBlockSize<br>
&gt;<br>
&gt; =3D=3D=3DProposal 2 : Depending on previous block size calculation and=
 previous Tx<br>
&gt; fee collected by miners=3D=3D=3D<br>
&gt;<br>
&gt;=C2=A0 =C2=A0TotalBlockSizeInLastButOneDifficulty =3D Sum of all Block =
size of first 2008<br>
&gt; blocks in last 2 difficulty period<br>
&gt;=C2=A0 =C2=A0TotalBlockSizeInLastDifficulty =3D Sum of all Block size o=
f second 2008<br>
&gt; blocks in last 2 difficulty period (This actually includes 8 blocks fr=
om<br>
&gt; last but one difficulty)<br>
&gt;<br>
&gt;=C2=A0 =C2=A0TotalTxFeeInLastButOneDifficulty =3D Sum of all Tx fees of=
 first 2008 blocks<br>
&gt; in last 2 difficulty period<br>
&gt;=C2=A0 =C2=A0TotalTxFeeInLastDifficulty =3D Sum of all Tx fees of secon=
d 2008 blocks in<br>
&gt; last 2 difficulty period (This actually includes 8 blocks from last bu=
t one<br>
&gt; difficulty)<br>
&gt;<br>
&gt;=C2=A0 =C2=A0If ( ( (Sum of first 4016 block size in last 2 difficulty =
period)/4016 &gt;<br>
&gt; 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty &gt;<br>
&gt; TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty =
&gt;<br>
&gt; TotalBlockSizeInLastButOneDifficulty) )<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0MaxBlockSize =3D TotalBlockSizeInLastDifficu=
lty * MaxBlockSize /<br>
&gt; TotalBlockSizeInLastButOneDifficulty<br>
&gt;=C2=A0 =C2=A0Else If ( ( (Sum of first 4016 block size in last 2 diffic=
ulty<br>
&gt; period)/4016 &lt; 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty &l=
t;<br>
&gt; TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty =
&lt;<br>
&gt; TotalBlockSizeInLastButOneDifficulty) )<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0MaxBlockSize =3D TotalBlockSizeInLastDifficu=
lty * MaxBlockSize /<br>
&gt; TotalBlockSizeInLastButOneDifficulty<br>
&gt;=C2=A0 =C2=A0Else<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0Keep the same MaxBlockSize<br>
&gt;<br>
&gt; =3D=3DRationale=3D=3D<br>
&gt;<br>
&gt; These two proposals have been derived after discussion on<br>
&gt; [<a href=3D"https://bitcointalk.org/index.php?topic=3D1154536.0" rel=
=3D"noreferrer" target=3D"_blank">https://bitcointalk.org/index.php?topic=
=3D1154536.0</a> BitcoinTalk] and<br>
&gt; [<a href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/201=
5-August/010285.html" rel=3D"noreferrer" target=3D"_blank">http://lists.lin=
uxfoundation.org/pipermail/bitcoin-dev/2015-August/010285.html</a><br>
&gt; bitcoin-dev mailing list]. The original idea and its evolution in the =
light<br>
&gt; of various arguements can be found [<a href=3D"http://upalc.com/maxblo=
cksize.php" rel=3D"noreferrer" target=3D"_blank">http://upalc.com/maxblocks=
ize.php</a> here].<br>
&gt;<br>
&gt; =3D=3D=3DProposal 1 : Depending only on previous block size calculatio=
n=3D=3D=3D<br>
&gt;<br>
&gt; This solution is derived directly from the indication of the problem. =
If<br>
&gt; transaction volume increases, then we will naturally see bigger blocks=
. On<br>
&gt; the contrary, if there are not enough transaction volume, but maximum =
block<br>
&gt; size is high, then only few blocks may sweep the mempool. Hence, if bl=
ock<br>
&gt; size is itself taken into consideration, then maximum block size can m=
ost<br>
&gt; rationally be derived. Moreover, this solution not only increases, but=
 also<br>
&gt; decreases the maximum block size, just like difficulty.<br>
&gt;<br>
&gt; =3D=3D=3DProposal 2 : Depending on previous block size calculation and=
 previous Tx<br>
&gt; fee collected by miners=3D=3D=3D<br>
&gt;<br>
&gt; This solution takes care of stable mining subsidy. It will not increas=
e<br>
&gt; maximum block size, if Tx fee collection is not increasing and thereby=
<br>
&gt; creating a Tx fee pressure on the market. On the other hand, though th=
e<br>
&gt; block size max cap is dynamically controlled, it is very difficult to =
game<br>
&gt; by any party because the increase or decrease of block size max cap wi=
ll<br>
&gt; take place in the same ratio of average block size increase or decreas=
e.<br>
&gt;<br>
&gt; =3D=3DCompatibility=3D=3D<br>
&gt;<br>
&gt; This is a hard-forking change to the Bitcoin protocol; anybody running=
 code<br>
&gt; that fully validates blocks must upgrade before the activation time or=
 they<br>
&gt; will risk rejecting a chain containing larger-than-one-megabyte blocks=
.<br>
&gt;<br>
&gt; =3D=3DOther solutions considered=3D=3D<br>
&gt;<br>
&gt; [<a href=3D"http://gtf.org/garzik/bitcoin/BIP100-blocksizechangepropos=
al.pdf" rel=3D"noreferrer" target=3D"_blank">http://gtf.org/garzik/bitcoin/=
BIP100-blocksizechangeproposal.pdf</a> Making<br>
&gt; Decentralized Economic Policy] - by Jeff Garzik<br>
&gt;<br>
&gt; [<a href=3D"https://bitcointalk.org/index.php?topic=3D1078521.0" rel=
=3D"noreferrer" target=3D"_blank">https://bitcointalk.org/index.php?topic=
=3D1078521.0</a> Elastic block cap with<br>
&gt; rollover penalties] - by Meni Rosenfeld<br>
&gt;<br>
&gt; [<a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0101.media=
wiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/bips/=
blob/master/bip-0101.mediawiki</a> Increase<br>
&gt; maximum block size] - by Gavin Andresen<br>
&gt;<br>
&gt; [<a href=3D"https://gist.github.com/sipa/c65665fc360ca7a176a6" rel=3D"=
noreferrer" target=3D"_blank">https://gist.github.com/sipa/c65665fc360ca7a1=
76a6</a> Block size following<br>
&gt; technological growth] - by Pieter Wuille<br>
&gt;<br>
&gt; [<a href=3D"https://lightning.network/lightning-network-paper.pdf" rel=
=3D"noreferrer" target=3D"_blank">https://lightning.network/lightning-netwo=
rk-paper.pdf</a> The Bitcoin Lightning<br>
&gt; Network: Scalable Off-Chain Instant Payments] - by Joseph Poon &amp; T=
haddeus<br>
&gt; Dryja<br>
&gt;<br>
&gt; =3D=3DDeployment=3D=3D<br>
&gt;<br>
&gt; If consensus is achieved, deployment can be made at a future block num=
ber at<br>
&gt; which difficulty will change.<br>
&gt;<br>
&gt;<br>
</div></div>&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.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.org=
/mailman/listinfo/bitcoin-dev</a><br>
&gt;<br>
</blockquote></div><br></div>

--089e0122aaeee92291051e4c5970--