path: root/97/c7cd8cb8b0264c7005962df522bd2b32e6d3d4

Return-Path: <roy@gnomon.org.uk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B44B0BCD
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Jun 2015 17:29:00 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from darla.gnomon.org.uk (darla.gnomon.org.uk [93.93.131.22])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F14551B7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Jun 2015 17:28:58 +0000 (UTC)
Received: from darla.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1])
	by darla.gnomon.org.uk (8.14.3/8.14.3) with ESMTP id t5OHSl34064051
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 24 Jun 2015 18:28:52 +0100 (BST)
	(envelope-from roy@darla.gnomon.org.uk)
Received: (from roy@localhost)
	by darla.gnomon.org.uk (8.14.3/8.14.1/Submit) id t5OHSloi064050;
	Wed, 24 Jun 2015 18:28:47 +0100 (BST) (envelope-from roy)
Date: Wed, 24 Jun 2015 18:28:47 +0100
From: Roy Badami <roy@gnomon.org.uk>
To: Raystonn <raystonn@hotmail.com>
Message-ID: <20150624172847.GD3192@giles.gnomon.org.uk>
References: <COL402-EAS745A879FDD8D3BAB8216D7CDAF0@phx.gbl>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <COL402-EAS745A879FDD8D3BAB8216D7CDAF0@phx.gbl>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,
	RP_MATCHES_RCVD 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] Draft BIP : fixed-schedule block size increase
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: Wed, 24 Jun 2015 17:29:00 -0000

60% of the hashrate can easily agree to force a softfork which reduces
the block size.  As soon as the fork occurs, there is a very strong
incentive for all the remaining 40% to go along with it: if they
don't, they're mining worthless blocks.

They can use a BIP-34 style mechanism to trigger the fork so there's
negligible risk to the miners.

On Wed, Jun 24, 2015 at 10:23:18AM -0700, Raystonn wrote:
> <p dir=3D"ltr">You really believe they would risk getting orphaned by ski=
pping the longer chain, just to attempt to reduce average block size? No, t=
hat doesn't happen today. Laziness in leaving the default size is common. B=
ut that is not collusion, nor an attempt to manipulate the block sizes of o=
ther miners.<br>
> </p>
> <div class=3D"gmail_quote">On 24 Jun 2015 10:05 am, Mark Friedenbach &lt;=
mark@friedenbach.org&gt; wrote:<br type=3D'attribution'><blockquote class=
=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><p dir=3D"ltr">They do so by not building on larger blocks</p>
> <div class=3D"elided-text">On Jun 23, 2015 9:31 PM, &#34;Raystonn&#34; &l=
t;<a href=3D"mailto:raystonn&#64;hotmail.com">raystonn&#64;hotmail.com</a>&=
gt; wrote:<br /><blockquote style=3D"margin:0 0 0 0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><p dir=3D"ltr">No, they can lower their own block=
 sizes.?? But they cannot currently lower the sizes of blocks mined by othe=
rs.?? That is not the same thing by any stretch of the imagination.</p>
> <div class=3D"elided-text">On 23 Jun 2015 8:50 pm, Jeff Garzik &lt;<a hre=
f=3D"mailto:jgarzik&#64;gmail.com">jgarzik&#64;gmail.com</a>&gt; wrote:<br =
/><blockquote style=3D"margin:0 0 0 0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr">Miners can collude today to lower the block si=
ze limit.<div><br /></div><div>In fact, this largely happens already out of=
 laziness - miners often follow the &#34;soft&#34; default limit set by Bit=
coin Core, to the point where you can chart when miners upgrade to new soft=
ware:??<a href=3D"http://hashingit.com/analysis/39-the-myth-of-the-megabyte=
-bitcoin-block">http://hashingit.com/analysis/39-the-myth-of-the-megabyte-b=
itcoin-block</a></div><div><br /></div><div><br /></div></div><div><br /><d=
iv>On Tue, Jun 23, 2015 at 8:05 PM, William Madden <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:will.madden&#64;novauri.com">will.madden&#64;novauri.com</a=
>&gt;</span> wrote:<br /><blockquote style=3D"margin:0 0 0 0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">Here are refutations of the approach in =
BIP-100 here:<br />
> <a href=3D"http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.p=
df">http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf</a><br=
 />
> <br />
> To recap BIP-100:<br />
> <br />
> 1) Hard form to remove static 1MB block size limit<br />
> 2) Add new floating block size limit set to 1MB<br />
> 3) Historical 32MB message limit remains<br />
> 4) Hard form on testnet 9/1/2015<br />
> 5) Hard form on main 1/11/2016<br />
> 6) 1MB limit changed via one-way lock in upgrade with a 12,000 block<br />
> threshold by 90% of blocks<br />
> 7) Limit increase or decrease may not exceed 2x in any one step<br />
> 8) Miners vote by encoding &#39;BV&#39;&#43;BlockSizeRequestValue into co=
inbase<br />
> scriptSig, e.g. &#34;/BV8000000/&#34; to vote for 8M.<br />
> 9) Votes are evaluated by dropping bottom 20% and top 20%, and then the<b=
r />
> most common floor (minimum) is chosen.<br />
> <br />
> 8MB limits doubling just under every 2 years makes a static value grow<br=
 />
> in a predictable manner.<br />
> <br />
> BIP-100 makes a static value grow (or more importantly potentially<br />
> shrink) in an unpredictable manner based on voting mechanics that are<br =
/>
> untested in this capacity in the bitcoin network.?? Introducing a highly<=
br />
> variable and untested dynamic into an already complex system is<br />
> unnecessarily risky.<br />
> <br />
> For example, the largely arbitrary voting rules listed in 9 above can be<=
br />
> gamed.?? If I control pools or have affiliates involved in pools that<br =
/>
> mine slightly more than 20% of blocks, I could wait until block sizes<br =
/>
> are 10MB, and then suddenly vote &#34;/BV5000000/&#34; for 20% of blocks =
and<br />
> &#34;/BV5000001/&#34; for the remaining 10%.?? If others don&#39;t consis=
tently vote<br />
> for the same &#34;/BV#/&#34; value, vote too consistently and have their =
value<br />
> thrown out as the top 20%, I could win the resize to half capacity<br />
> &#34;/BV5000001/&#34; because it was the lowest repeated value not in the=
 bottom<br />
> 20%.<br />
> <br />
> I could use this to force an exodus to my sidechain/alt coin, or to<br />
> choke out the bitcoin network.?? A first improvement would be to only let=
<br />
> BIP-100 raise the cap and not lower it, but if I can think of a<br />
> vulnerability off the top of my head, there will be others on the other<b=
r />
> side of the equation that have not been thought of.?? Why bother<br />
> introducing a rube goldberg machine like voting when a simple 8mb cap<br =
/>
> with predictable growth gets the job done, potentially permanently?<br />
> <div><div><br />
> <br />
> On 6/23/2015 9:43 PM, odinn wrote:<br />
> &gt; -----BEGIN PGP SIGNED MESSAGE-----<br />
> &gt; Hash: SHA1<br />
> &gt;<br />
> &gt; 1) Hard fork not (necessarily) needed<br />
> &gt; 2) See Garzik&#39;s BIP 100, better (this is not meant to say &#34;s=
uperior to<br />
> &gt; your stuff,&#34; but rather simply to say, &#34;Better you should wo=
rk with<br />
> &gt; Garzik to implement BIP-100, that would be good&#34;)<br />
> &gt; 3) See points 1 and 2 above<br />
> &gt; 4) If still reading... changes should be (as you seem to have been<b=
r />
> &gt; trying to lean towards)... lean towards gradual change; hence, chang=
es<br />
> &gt; that would flow from this BIP would be better off oriented in a<br />
> &gt; process that dies not require the &#34;way you have done it.&#34;<br=
 />
> &gt;<br />
> &gt; You did address that, to be fair - in your TODO, this link:<br />
> &gt; <a href=3D"http://gavinandresen.ninja/time-to-roll-out-bigger-blocks=
">http://gavinandresen.ninja/time-to-roll-out-bigger-blocks</a><br />
> &gt;<br />
> &gt; contained the following link:<br />
> &gt;<br />
> &gt; <a href=3D"http://gavinandresen.ninja/bigger-blocks-another-way">htt=
p://gavinandresen.ninja/bigger-blocks-another-way</a><br />
> &gt;<br />
> &gt; However, in reading that, I didn&#39;t see any meaningful statements=
 that<br />
> &gt; would refute the approach in Garzik&#39;s BIP-100.<br />
> &gt;<br />
> &gt; Maybe a better way to say this is,<br />
> &gt;<br />
> &gt; Work with Jeff Garzik (which I am sure you are already having such<b=
r />
> &gt; discussions in private) as well as the list discussions,<br />
> &gt; Move forward on BIP-100 with Garzik and other developers (not such a=
<br />
> &gt; bad plan really) and don&#39;t get caught up in XT.?? (If you feel y=
ou can<br />
> &gt; develop XT further, that is your thing but it would perhaps make you=
<br />
> &gt; lose focus, work together with other developers.)<br />
> &gt;<br />
> &gt; Relax into the process.?? Things will be ok.<br />
> &gt;<br />
> &gt; Respectfully,<br />
> &gt;<br />
> &gt; - -O<br />
> &gt;<br />
> &gt; On 06/22/2015 11:18 AM, Gavin Andresen wrote:<br />
> &gt;&gt; I promised to write a BIP after I&#39;d implemented<br />
> &gt;&gt; increase-the-maximum-block-size code, so here it is. It also liv=
es<br />
> &gt;&gt; at:<br />
> &gt;&gt; <a href=3D"https://github.com/gavinandresen/bips/blob/blocksize/=
bip-8MB.mediawiki">https://github.com/gavinandresen/bips/blob/blocksize/bip=
-8MB.mediawiki</a><br />
> &gt;&gt;<br />
> &gt;&gt;?? I don&#39;t expect any proposal to please everybody; there are=
<br />
> &gt;&gt; unavoidable tradeoffs to increasing the maximum block size. I<br=
 />
> &gt;&gt; prioritize implementation simplicity -- it is hard to write<br />
> &gt;&gt; consensus-critical code, so simpler is better.<br />
> &gt;&gt;<br />
> &gt;&gt;<br />
> &gt;&gt;<br />
> &gt;&gt;<br />
> &gt;&gt; BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andrese=
n<br />
> &gt;&gt; &lt;<a href=3D"mailto:gavinandresen&#64;gmail.com">gavinandresen=
&#64;gmail.com</a> &lt;mailto:<a href=3D"mailto:gavinandresen&#64;gmail.com=
">gavinandresen&#64;gmail.com</a>&gt;&gt; Status:<br />
> &gt;&gt; Draft Type: Standards Track Created: 2015-06-22<br />
> &gt;&gt;<br />
> &gt;&gt; &#61;&#61;Abstract&#61;&#61;<br />
> &gt;&gt;<br />
> &gt;&gt; This BIP proposes replacing the fixed one megabyte maximum block=
<br />
> &gt;&gt; size with a maximum size that grows over time at a predictable<b=
r />
> &gt;&gt; rate.<br />
> &gt;&gt;<br />
> &gt;&gt; &#61;&#61;Motivation&#61;&#61;<br />
> &gt;&gt;<br />
> &gt;&gt; Transaction volume on the Bitcoin network has been growing, and<=
br />
> &gt;&gt; will soon reach the one-megabyte-every-ten-minutes limit imposed=
 by<br />
> &gt;&gt; the one megabyte maximum block size. Increasing the maximum size=
<br />
> &gt;&gt; reduces the impact of that limit on Bitcoin adoption and growth.=
<br />
> &gt;&gt;<br />
> &gt;&gt; &#61;&#61;Specification&#61;&#61;<br />
> &gt;&gt;<br />
> &gt;&gt; After deployment on the network (see the Deployment section for<=
br />
> &gt;&gt; details), the maximum allowed size of a block on the main networ=
k<br />
> &gt;&gt; shall be calculated based on the timestamp in the block header.<=
br />
> &gt;&gt;<br />
> &gt;&gt; The maximum size shall be 8,000,000 bytes at a timestamp of<br />
> &gt;&gt; 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double=
<br />
> &gt;&gt; every 63,072,000 seconds (two years, ignoring leap years), until=
<br />
> &gt;&gt; 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size=
 of<br />
> &gt;&gt; blocks in between doublings will increase linearly based on the<=
br />
> &gt;&gt; block&#39;s timestamp. The maximum size of blocks after 2036-01-=
06<br />
> &gt;&gt; 00:00:00 UTC shall be 8,192,000,000 bytes.<br />
> &gt;&gt;<br />
> &gt;&gt; Expressed in pseudo-code, using integer math:<br />
> &gt;&gt;<br />
> &gt;&gt; function max_block_size(block_timestamp):<br />
> &gt;&gt;<br />
> &gt;&gt; time_start &#61; 1452470400 time_double &#61; 60*60*24*365*2 siz=
e_start &#61;<br />
> &gt;&gt; 8000000 if block_timestamp &gt;&#61; time_start&#43;time_double*=
10 return<br />
> &gt;&gt; size_start * 2^10<br />
> &gt;&gt;<br />
> &gt;&gt; // Piecewise-linear-between-doublings growth: time_delta &#61;<b=
r />
> &gt;&gt; block_timestamp - t_start doublings &#61; time_delta / time_doub=
le<br />
> &gt;&gt; remainder &#61; time_delta % time_double interpolate &#61; (size=
_start *<br />
> &gt;&gt; 2^doublings * remainder) / time_double max_size &#61; size_start=
 *<br />
> &gt;&gt; 2^doublings &#43; interpolate<br />
> &gt;&gt;<br />
> &gt;&gt; return max_size<br />
> &gt;&gt;<br />
> &gt;&gt; &#61;&#61;Deployment&#61;&#61;<br />
> &gt;&gt;<br />
> &gt;&gt; Deployment shall be controlled by hash-power supermajority vote<=
br />
> &gt;&gt; (similar to the technique used in BIP34), but the earliest possi=
ble<br />
> &gt;&gt; activation time is 2016-01-11 00:00:00 UTC.<br />
> &gt;&gt;<br />
> &gt;&gt; Activation is achieved when 750 of 1,000 consecutive blocks in t=
he<br />
> &gt;&gt; best chain have a version number with bits 3 and 14 set (0x20000=
004<br />
> &gt;&gt; in hex). The activation time will be the timestamp of the 750&#3=
9;th<br />
> &gt;&gt; block plus a two week (1,209,600 second) grace period to give an=
y<br />
> &gt;&gt; remaining miners or services time to upgrade to support larger<b=
r />
> &gt;&gt; blocks. If a supermajority is achieved more than two weeks befor=
e<br />
> &gt;&gt; 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11<=
br />
> &gt;&gt; 00:00:00 UTC.<br />
> &gt;&gt;<br />
> &gt;&gt; Block version numbers are used only for activation; once activat=
ion<br />
> &gt;&gt; is achieved, the maximum block size shall be as described in the=
<br />
> &gt;&gt; specification section, regardless of the version number of the<b=
r />
> &gt;&gt; block.<br />
> &gt;&gt;<br />
> &gt;&gt;<br />
> &gt;&gt; &#61;&#61;Rationale&#61;&#61;<br />
> &gt;&gt;<br />
> &gt;&gt; The initial size of 8,000,000 bytes was chosen after testing the=
<br />
> &gt;&gt; current reference implementation code with larger block sizes an=
d<br />
> &gt;&gt; receiving feedback from miners stuck behind bandwidth-constraine=
d<br />
> &gt;&gt; networks (in particular, Chinese miners behind the Great Firewal=
l<br />
> &gt;&gt; of China).<br />
> &gt;&gt;<br />
> &gt;&gt; The doubling interval was chosen based on long-term growth trend=
s<br />
> &gt;&gt; for CPU power, storage, and Internet bandwidth. The 20-year limi=
t<br />
> &gt;&gt; was chosen because exponential growth cannot continue forever.<b=
r />
> &gt;&gt;<br />
> &gt;&gt; Calculations are based on timestamps and not blockchain height<b=
r />
> &gt;&gt; because a timestamp is part of every block&#39;s header. This al=
lows<br />
> &gt;&gt; implementations to know a block&#39;s maximum size after they ha=
ve<br />
> &gt;&gt; downloaded it&#39;s header, but before downloading any transacti=
ons.<br />
> &gt;&gt;<br />
> &gt;&gt; The deployment plan is taken from Jeff Garzik&#39;s proposed BIP=
100<br />
> &gt;&gt; block size increase, and is designed to give miners, merchants,<=
br />
> &gt;&gt; and full-node-running-end-users sufficient time to upgrade to<br=
 />
> &gt;&gt; software that supports bigger blocks. A 75% supermajority was<br=
 />
> &gt;&gt; chosen so that one large mining pool does not have effective vet=
o<br />
> &gt;&gt; power over a blocksize increase. The version number scheme is<br=
 />
> &gt;&gt; designed to be compatible with Pieter&#39;s Wuille&#39;s propose=
d &#34;Version<br />
> &gt;&gt; bits&#34; BIP.<br />
> &gt;&gt;<br />
> &gt;&gt; TODO: summarize objections/arguments from<br />
> &gt;&gt; <a href=3D"http://gavinandresen.ninja/time-to-roll-out-bigger-bl=
ocks">http://gavinandresen.ninja/time-to-roll-out-bigger-blocks</a>.<br />
> &gt;&gt;<br />
> &gt;&gt; TODO: describe other proposals and their advantages/disadvantage=
s<br />
> &gt;&gt; over this proposal.<br />
> &gt;&gt;<br />
> &gt;&gt;<br />
> &gt;&gt; &#61;&#61;Compatibility&#61;&#61;<br />
> &gt;&gt;<br />
> &gt;&gt; This is a hard-forking change to the Bitcoin protocol; anybody<b=
r />
> &gt;&gt; running code that fully validates blocks must upgrade before the=
<br />
> &gt;&gt; activation time or they will risk rejecting a chain containing<b=
r />
> &gt;&gt; larger-than-one-megabyte blocks.<br />
> &gt;&gt;<br />
> &gt;&gt; Simplified Payment Verification software is not affected, unless=
<br />
> &gt;&gt; it makes assumptions about the maximum depth of a transaction&#3=
9;s<br />
> &gt;&gt; merkle branch based on the minimum size of a transaction and the=
<br />
> &gt;&gt; maximum block size.<br />
> &gt;&gt;<br />
> &gt;&gt; &#61;&#61;Implementation&#61;&#61;<br />
> &gt;&gt;<br />
> &gt;&gt; <a href=3D"https://github.com/gavinandresen/bitcoinxt/tree/block=
size_fork">https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork</=
a><br />
> &gt;&gt;<br />
> &gt;&gt;<br />
> &gt;&gt;<br />
> &gt;&gt; _______________________________________________ bitcoin-dev mail=
ing<br />
> &gt;&gt; list <a href=3D"mailto:bitcoin-dev&#64;lists.linuxfoundation.org=
">bitcoin-dev&#64;lists.linuxfoundation.org</a><br />
> &gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bi=
tcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</=
a><br />
> &gt;&gt;<br />
> &gt;<br />
> &gt; - --<br />
> &gt; <a href=3D"http://abis.io">http://abis.io</a> ~<br />
> &gt; &#34;a protocol concept to enable decentralization<br />
> &gt; and expansion of a giving economy, and a new social good&#34;<br />
> &gt; <a href=3D"https://keybase.io/odinn">https://keybase.io/odinn</a><br=
 />
> &gt; -----BEGIN PGP SIGNATURE-----<br />
> &gt; Version: GnuPG v1<br />
> &gt;<br />
> &gt; iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175<br =
/>
> &gt; Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO&#43;=
<br />
> &gt; K2h3DmAcA6W/Thk0C2cV3ewv&#43;OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw=
<br />
> &gt; OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN<br =
/>
> &gt; fZAeLCuwuN2qWMrVrr&#43;cbpCXjEuE1xZG3WEj7ppYoGR&#43;AgF/Y5/U1j7S4PVp=
k85s<br />
> &gt; CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo&#61;=
<br />
> &gt; &#61;ft62<br />
> &gt; -----END PGP SIGNATURE-----<br />
> &gt; _______________________________________________<br />
> &gt; bitcoin-dev mailing list<br />
> &gt; <a href=3D"mailto:bitcoin-dev&#64;lists.linuxfoundation.org">bitcoin=
-dev&#64;lists.linuxfoundation.org</a><br />
> &gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoi=
n-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><b=
r />
> &gt;<br />
> _______________________________________________<br />
> bitcoin-dev mailing list<br />
> <a href=3D"mailto:bitcoin-dev&#64;lists.linuxfoundation.org">bitcoin-dev&=
#64;lists.linuxfoundation.org</a><br />
> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev=
">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br />
> </div></div></blockquote></div><br /></div>
> </blockquote></div><br />_______________________________________________<=
br />
> bitcoin-dev mailing list<br />
> <a href=3D"mailto:bitcoin-dev&#64;lists.linuxfoundation.org">bitcoin-dev&=
#64;lists.linuxfoundation.org</a><br />
> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev=
">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br />
> <br /></blockquote></div>
> </blockquote></div>

> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev