diff options
| author | Eric Lombrozo <elombrozo@gmail.com> | 2015-08-03 02:01:02 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-08-03 09:01:09 +0000 |
| commit | 4e51bd8833b6415b398b0d88d2657d1d7b199f3d (patch) | |
| tree | b7407c319113171b3d5f1596a4b0f8c510d1e9b8 | |
| parent | f65bebdd3b4cdcae05578f8749d1a51f789d78cc (diff) | |
| download | pi-bitcoindev-4e51bd8833b6415b398b0d88d2657d1d7b199f3d.tar.gz pi-bitcoindev-4e51bd8833b6415b398b0d88d2657d1d7b199f3d.zip | |
Re: [bitcoin-dev] A reason we can all agree on to increase block size
| -rw-r--r-- | 41/0445f5d072923a89eafd734eb4fdda2d0333cf | 424 |
1 files changed, 424 insertions, 0 deletions
diff --git a/41/0445f5d072923a89eafd734eb4fdda2d0333cf b/41/0445f5d072923a89eafd734eb4fdda2d0333cf new file mode 100644 index 000000000..f410b5dc1 --- /dev/null +++ b/41/0445f5d072923a89eafd734eb4fdda2d0333cf @@ -0,0 +1,424 @@ +Return-Path: <elombrozo@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 16E648A7 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 3 Aug 2015 09:01:09 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com + [209.85.220.48]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E0D2C143 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 3 Aug 2015 09:01:07 +0000 (UTC) +Received: by pasy3 with SMTP id y3so9921535pas.2 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 03 Aug 2015 02:01:07 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; + h=subject:mime-version:content-type:from:in-reply-to:date:cc + :message-id:references:to; + bh=IPCmP0hTr9xNhv/HNOIWvd0lKq9mc7GZxThpyQx3jcQ=; + b=cGp+K5sddqut6+Cj8R7Fo4s2/NXfahnCSA+7AooZ0XIzZ2vYW6ababXVUa93OJ1k+i + fR0bIj5y1NTvYEnRYDmPYJAh+auUNeMFRxpKLguWm9VaZIa6rwFIlinZ6qN853hf0ggE + drpUQqW6w/EXx4ftFtFkcQAzLvSddRGGB6d+ENQvVOzcd6LvdeksfaUuj4Gu93kxPAU1 + oEMvntx7lLUcpsXIfEy8zLSglidwWDEVSRYYmnwzRwYT3cncWd/S6yp2d6Rq2G2IfHV8 + /hGTrNbUg4LZ2con84dE0qXi7UQhnCnQIK21cORY70xesZyFHaAdEJdaCfz4ayKz9Fzt + COHw== +X-Received: by 10.66.221.138 with SMTP id qe10mr32794071pac.45.1438592467602; + Mon, 03 Aug 2015 02:01:07 -0700 (PDT) +Received: from [192.168.1.107] (cpe-76-167-237-202.san.res.rr.com. + [76.167.237.202]) by smtp.gmail.com with ESMTPSA id + cr4sm16768026pac.10.2015.08.03.02.01.04 + (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); + Mon, 03 Aug 2015 02:01:05 -0700 (PDT) +Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) +Content-Type: multipart/signed; + boundary="Apple-Mail=_1ED4908E-80B8-4F2A-B4A5-676D6BA5CE7E"; + protocol="application/pgp-signature"; micalg=pgp-sha512 +X-Pgp-Agent: GPGMail 2.5 +From: Eric Lombrozo <elombrozo@gmail.com> +In-Reply-To: <CAAO2FKFkMHy0i3GV1aHXu8Hiw5uVnSE2pk17n2mCqOfY-D8Weg@mail.gmail.com> +Date: Mon, 3 Aug 2015 02:01:02 -0700 +Message-Id: <9D6A80DF-83E6-4F98-B7C2-2EE2F79CB2D1@gmail.com> +References: <CANe1mWxsAPzWut_gDqe4R-SkDPBYM392NzeVqbUzjwh+pydsWQ@mail.gmail.com> + <CALqxMTEMajz6oHnGvocxy=xDFMBc1LaX1iWYM=w1PF0rH3syFg@mail.gmail.com> + <55BF153B.9030001@bitcartel.com> + <CAAO2FKEBBS5wxefGCPcurcRGg76sORrBMHvd2SSNiW1q_zWBWQ@mail.gmail.com> + <CALqxMTE69h5OcnDSqSMeK+BbzFaScEqouQG=pVuyWrqG17BeXQ@mail.gmail.com> + <CAAO2FKHZa_3VzMhQ-EVK9MzSnNGCfwb_GcKJHV52bYcWayJvig@mail.gmail.com> + <291F9D27-024C-4982-B638-1ACDC4FE0672@gmail.com> + <CAAO2FKGGyjJT8UhW9m1ZMRY4gmjf3F05mjW1eZ2byT+dwM28Ow@mail.gmail.com> + <9A5F47B8-AD42-46CB-993B-661BAD0E62AC@gmail.com> + <CAAO2FKFkMHy0i3GV1aHXu8Hiw5uVnSE2pk17n2mCqOfY-D8Weg@mail.gmail.com> +To: Hector Chu <hectorchu@gmail.com> +X-Mailer: Apple Mail (2.2098) +X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,FREEMAIL_REPLY,HTML_MESSAGE, + RCVD_IN_DNSWL_LOW autolearn=no 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> +Subject: Re: [bitcoin-dev] A reason we can all agree on to increase block + size +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: Mon, 03 Aug 2015 09:01:09 -0000 + + +--Apple-Mail=_1ED4908E-80B8-4F2A-B4A5-676D6BA5CE7E +Content-Type: multipart/alternative; + boundary="Apple-Mail=_A6485220-5643-4509-9DE1-FB5C37267D62" + + +--Apple-Mail=_A6485220-5643-4509-9DE1-FB5C37267D62 +Content-Transfer-Encoding: quoted-printable +Content-Type: text/plain; + charset=utf-8 + + +> On Aug 3, 2015, at 1:52 AM, Hector Chu <hectorchu@gmail.com> wrote: +>=20 +> On 3 August 2015 at 09:38, Eric Lombrozo <elombrozo@gmail.com = +<mailto:elombrozo@gmail.com>> wrote: +> We already have much more efficient, far more scalable systems that = +allow this kind of cooperation you speak of without the inconveniences = +of blockchains and such. +>=20 +> There is a degree of difference between cooperation in day-to-day = +usage of the system and cooperation in the rare cases the system has a = +bug. +>=20 + +If it=E2=80=99s an as-of-yet unidentified issue that comes up, = +yes=E2=80=A6obviously we can=E2=80=99t plan for everything and we=E2=80=99= +ll make some mistakes. But here we=E2=80=99re talking about specific = +well-known issues (or at least well-known today) for which several = +people have proposed potential solutions. However, these things have = +been all but ignored in the public discourse. + +> These incidents do, fortunately, present some of the better sides of = +humanity=E2=80=A6but=E2=80=A6the design of the network *broke* - and for = +reasons that are now well understood to be only worsened by larger = +blocks. These incidents are *not supposed to happen* - and if they do, = +it means we=E2=80=99ve botched something up and need to fix it. And by = +fix it, I mean fix the protocol so that given our best understanding of = +things in the present we can significantly reduce the potential for its = +occurrence in the future. +>=20 +> Distribution by consensus is inherently a fragile system. The network = +will continue to break again and again as long as programmers are = +fallible. But the types of bugs that occur will change over time as we = +learn the best practices for maintaining the system. + +I agree. But again, once we=E2=80=99ve identified specific issues, it is = +irresponsible to continue to pretend they don=E2=80=99t exist=E2=80=A6and = +to more highly prioritize changes that can only make the problem worse. + +Again, for the record, I am not against ultimately allowing bigger = +blocks. I think it would be a good thing to be able to do this=E2=80=A6and= + my main concerns are not around things like equipment costs or typical = +household bandwidth. I just think security is a more important feature = +than greater throughput and prioritize it thusly. + + +> The correct incentives here were not due to people potentially losing = +a lot of money. The incentives here were well-intentioned altruism. Some = +miners lost money as a result of these actions=E2=80=A6and they didn=E2=80= +=99t put up a fight. if you want to design a system around the = +assumption that this is how all such incidents will be resolved, please = +don=E2=80=99t spoil this for the rest of us. +>=20 +> Altruism is a facade that hides other motivations. The party = +cooperating with the miners losing money were doing so to maintain good = +relationships with those miners and to make sure those miners stay = +within the system and not attack it. + +I don=E2=80=99t disagree=E2=80=A6clearly even the miners that lost money = +believed that consensus was more valuable to them than a few bitcoins. = +However, it seems to be EXTREMELY dangerous to assume that it will = +always work out this way. What=E2=80=99s to stop a mining majority from = +deciding on-the-fly they want to keep a particular consensus rule that = +benefits them even if the core developers disagree? + +>=20 +> - Eric +>=20 +>> On Aug 3, 2015, at 1:31 AM, Hector Chu <hectorchu@gmail.com = +<mailto:hectorchu@gmail.com>> wrote: +>>=20 +>> What's wrong with a little cooperation to resolve things now and = +then? Man is not an island unto himself, we compete with each other and = +we cooperate with each other occasionally if it's mutually beneficial. +>>=20 +>> You said yourself that a lot of money would have been lost if the two = +hard forks cited weren't resolved - that's the correct incentives at = +work again. +>>=20 +>> On 3 August 2015 at 09:20, Eric Lombrozo <elombrozo@gmail.com = +<mailto:elombrozo@gmail.com>> wrote: +>> There have already been two notable incidents requiring manual = +intervention and good-faith cooperation between core devs and mining = +pool operators that would have either never gotten resolved alone or = +would have ended up costing a lot of people a lot of money had no action = +been taken (March 2013 and July 2015). They were both caused by = +consensus disagreement that directly or indirectly were brought about by = +bigger blocks. There is *strong* evidence=E2=80=A6and a great deal of = +theory explaining it=E2=80=A6that links larger blocks with the = +propensity for consensus forks that require manual intervention. +>>=20 +>> Please, can we stop saying this is merely about decentralization and = +trustlessness? The very model upon which the security of the system is = +based *broke*=E2=80=A6as in, we were only able to recover because a few = +individuals deliberately manipulated the consensus rules to fix it = +manually. Shouldn=E2=80=99t we more highly prioritize fixing the issues = +that can lead to these incidents than trying to increase throughput? = +Increasing block size cannot possibly make these forking tendencies = +better=E2=80=A6but it very well could make them worse. +>>=20 +>> - Eric +>>=20 +>>> On Aug 3, 2015, at 1:06 AM, Hector Chu via bitcoin-dev = +<bitcoin-dev@lists.linuxfoundation.org = +<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: +>>>=20 +>>> On 3 August 2015 at 08:53, Adam Back <adam@cypherspace.org = +<mailto:adam@cypherspace.org>> wrote: +>>> Again this should not be a political or business compromise model - = +we +>>> must focus on scientific evaluation, technical requirements and +>>> security. +>>>=20 +>>> I will assert that the block size is political because it affects = +nearly all users to some degree and not all those users are technically = +inclined or care to keep decentralisation in the current configuration = +as you do. This debate has forgotten the current and future users of = +Bitcoin. Most of them think the hit to node count in the short term = +preferable to making it expensive and competitive to transact. +>>>=20 +>>> We all need a little faith that the system will reorganise and = +readjust after the move to big blocks in a way that still has a = +reasonable degree of decentralisation and trustlessness. The incentives = +of Bitcoin remain, so everyone's decentralised decision throughout the = +system, from miners, merchants and users, will continue to act according = +to those incentives. +>>> _______________________________________________ +>>> bitcoin-dev mailing list +>>> bitcoin-dev@lists.linuxfoundation.org = +<mailto:bitcoin-dev@lists.linuxfoundation.org> +>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev = +<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev> +>>=20 +>>=20 +>=20 +>=20 + + +--Apple-Mail=_A6485220-5643-4509-9DE1-FB5C37267D62 +Content-Transfer-Encoding: quoted-printable +Content-Type: text/html; + charset=utf-8 + +<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = +charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = +-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = +class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div = +class=3D"">On Aug 3, 2015, at 1:52 AM, Hector Chu <<a = +href=3D"mailto:hectorchu@gmail.com" class=3D"">hectorchu@gmail.com</a>>= + wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div = +dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div = +class=3D"gmail_quote">On 3 August 2015 at 09:38, Eric Lombrozo <span = +dir=3D"ltr" class=3D""><<a href=3D"mailto:elombrozo@gmail.com" = +target=3D"_blank" class=3D"">elombrozo@gmail.com</a>></span> = +wrote:<br class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 = +0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div = +style=3D"word-wrap:break-word" class=3D""><div class=3D"">We already = +have much more efficient, far more scalable systems that allow this kind = +of cooperation you speak of without the inconveniences of blockchains = +and such.</div></div></blockquote><div class=3D""><br = +class=3D""></div><div class=3D"">There is a degree of difference between = +cooperation in day-to-day usage of the system and cooperation in the = +rare cases the system has a bug.</div><div class=3D""><br = +class=3D""></div></div></div></div></div></blockquote><div><br = +class=3D""></div><div>If it=E2=80=99s an as-of-yet unidentified issue = +that comes up, yes=E2=80=A6obviously we can=E2=80=99t plan for = +everything and we=E2=80=99ll make some mistakes. But here we=E2=80=99re = +talking about specific well-known issues (or at least well-known today) = +for which several people have proposed potential solutions. However, = +these things have been all but ignored in the public discourse.</div><br = +class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div = +dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div = +class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 = +0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div = +style=3D"word-wrap:break-word" class=3D""><div class=3D"">These = +incidents do, fortunately, present some of the better sides of = +humanity=E2=80=A6but=E2=80=A6the design of the network *broke* - and for = +reasons that are now well understood to be only worsened by larger = +blocks. These incidents are *not supposed to happen* - and if they do, = +it means we=E2=80=99ve botched something up and need to fix it. And by = +fix it, I mean fix the protocol so that given our best understanding of = +things in the present we can significantly reduce the potential for its = +occurrence in the future.</div></div></blockquote><div class=3D""><br = +class=3D""></div><div class=3D"">Distribution by consensus is inherently = +a fragile system. The network will continue to break again and again as = +long as programmers are fallible. But the types of bugs that occur will = +change over time as we learn the best practices for maintaining the = +system.</div></div></div></div></div></blockquote><div><br = +class=3D""></div>I agree. But again, once we=E2=80=99ve identified = +specific issues, it is irresponsible to continue to pretend they don=E2=80= +=99t exist=E2=80=A6and to more highly prioritize changes that can only = +make the problem worse.</div><div><br class=3D""></div><div>Again, for = +the record, I am not against ultimately allowing bigger blocks. I think = +it would be a good thing to be able to do this=E2=80=A6and my main = +concerns are not around things like equipment costs or typical household = +bandwidth. I just think security is a more important feature than = +greater throughput and prioritize it thusly.<br class=3D""><div><br = +class=3D""></div><br class=3D""><blockquote type=3D"cite" class=3D""><div = +dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div = +class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 = +0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div = +style=3D"word-wrap:break-word" class=3D""><div class=3D"">The correct = +incentives here were not due to people potentially losing a lot of = +money. The incentives here were well-intentioned altruism. Some miners = +lost money as a result of these actions=E2=80=A6and they didn=E2=80=99t = +put up a fight. if you want to design a system around the assumption = +that this is how all such incidents will be resolved, please don=E2=80=99t= + spoil this for the rest of us.<br = +class=3D""></div></div></blockquote><div class=3D""><br = +class=3D""></div><div class=3D"">Altruism is a facade that hides other = +motivations. The party cooperating with the miners losing money were = +doing so to maintain good relationships with those miners and to make = +sure those miners stay within the system and not attack = +it.</div></div></div></div></blockquote><div><br class=3D""></div>I = +don=E2=80=99t disagree=E2=80=A6clearly even the miners that lost money = +believed that consensus was more valuable to them than a few bitcoins. = +However, it seems to be EXTREMELY dangerous to assume that it will = +always work out this way. What=E2=80=99s to stop a mining majority from = +deciding on-the-fly they want to keep a particular consensus rule that = +benefits them even if the core developers disagree?</div><div><br = +class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div = +dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div = +class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 = +0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div = +style=3D"word-wrap:break-word" class=3D""><div class=3D""></div><span = +class=3D"HOEnZb"><font color=3D"#888888" class=3D""><div class=3D""><br = +class=3D""></div><div class=3D"">- Eric</div></font></span><div = +class=3D""><div class=3D"h5"><div class=3D""><br class=3D""><div = +class=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On Aug = +3, 2015, at 1:31 AM, Hector Chu <<a href=3D"mailto:hectorchu@gmail.com"= + target=3D"_blank" class=3D"">hectorchu@gmail.com</a>> = +wrote:</div><br class=3D""><div class=3D""><div dir=3D"ltr" = +class=3D"">What's wrong with a little cooperation to resolve things now = +and then? Man is not an island unto himself, we compete with each other = +and we cooperate with each other occasionally if it's mutually = +beneficial.<div class=3D""><br class=3D""></div><div class=3D"">You said = +yourself that a lot of money would have been lost if the two hard forks = +cited weren't resolved - that's the correct incentives at work = +again.</div></div><div class=3D"gmail_extra"><br class=3D""><div = +class=3D"gmail_quote">On 3 August 2015 at 09:20, Eric Lombrozo <span = +dir=3D"ltr" class=3D""><<a href=3D"mailto:elombrozo@gmail.com" = +target=3D"_blank" class=3D"">elombrozo@gmail.com</a>></span> = +wrote:<br class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 = +0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div = +style=3D"word-wrap:break-word" class=3D"">There have already been two = +notable incidents requiring manual intervention and good-faith = +cooperation between core devs and mining pool operators that would have = +either never gotten resolved alone or would have ended up costing a lot = +of people a lot of money had no action been taken (March 2013 and July = +2015). They were both caused by consensus disagreement that directly or = +indirectly were brought about by bigger blocks. There is *strong* = +evidence=E2=80=A6and a great deal of theory explaining it=E2=80=A6that = +links larger blocks with the propensity for consensus forks that require = +manual intervention.<div class=3D""><br class=3D""></div><div = +class=3D"">Please, can we stop saying this is merely about = +decentralization and trustlessness? The very model upon which the = +security of the system is based *broke*=E2=80=A6as in, we were only able = +to recover because a few individuals deliberately manipulated the = +consensus rules to fix it manually. Shouldn=E2=80=99t we more highly = +prioritize fixing the issues that can lead to these incidents than = +trying to increase throughput? Increasing block size cannot possibly = +make these forking tendencies better=E2=80=A6but it very well could make = +them worse.</div><span class=3D""><font color=3D"#888888" class=3D""><div = +class=3D""><br class=3D""></div><div class=3D"">- = +Eric</div></font></span><div class=3D""><br class=3D""><div = +class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div = +class=3D""><div class=3D"">On Aug 3, 2015, at 1:06 AM, Hector Chu via = +bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" = +target=3D"_blank" class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>>= + wrote:</div><br class=3D""></div></div><div class=3D""><div = +class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div = +class=3D"gmail_extra"><div class=3D"gmail_quote">On 3 August 2015 at = +08:53, Adam Back <span dir=3D"ltr" class=3D""><<a = +href=3D"mailto:adam@cypherspace.org" target=3D"_blank" = +class=3D"">adam@cypherspace.org</a>></span> wrote:<br = +class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = +.8ex;border-left:1px #ccc solid;padding-left:1ex">Again this should not = +be a political or business compromise model - we<br class=3D""> +must focus on scientific evaluation, technical requirements and<br = +class=3D""> +security.<br class=3D""></blockquote><div class=3D""><br = +class=3D""></div>I will assert that the block size is political because = +it affects nearly all users to some degree and not all those users are = +technically inclined or care to keep decentralisation in the current = +configuration as you do. This debate has forgotten the current and = +future users of Bitcoin. Most of them think the hit to node count in the = +short term preferable to making it expensive and competitive to = +transact.</div><div class=3D"gmail_quote"><br class=3D""></div><div = +class=3D"gmail_quote">We all need a little faith that the system will = +reorganise and readjust after the move to big blocks in a way that still = +has a reasonable degree of decentralisation and trustlessness. The = +incentives of Bitcoin remain, so everyone's decentralised decision = +throughout the system, from miners, merchants and users, will continue = +to act according to those incentives.</div></div></div></div></div><span = +class=3D""> +_______________________________________________<br class=3D"">bitcoin-dev = +mailing list<br class=3D""><a = +href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" = +class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D""><a = +href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +target=3D"_blank" = +class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= +/a><br class=3D""></span></div></blockquote></div><br = +class=3D""></div></div></blockquote></div><br class=3D""></div> +</div></blockquote></div><br = +class=3D""></div></div></div></div></blockquote></div><br = +class=3D""></div></div> +</div></blockquote></div><br class=3D""></body></html>= + +--Apple-Mail=_A6485220-5643-4509-9DE1-FB5C37267D62-- + +--Apple-Mail=_1ED4908E-80B8-4F2A-B4A5-676D6BA5CE7E +Content-Transfer-Encoding: 7bit +Content-Disposition: attachment; + filename=signature.asc +Content-Type: application/pgp-signature; + name=signature.asc +Content-Description: Message signed with OpenPGP using GPGMail + +-----BEGIN PGP SIGNATURE----- +Comment: GPGTools - https://gpgtools.org + +iQIcBAEBCgAGBQJVvy3OAAoJEJNAI64YFENUcb0P/3nOiopGk2CoFksA2C+2iTdv +p3DUS/Z+m8/CfkekJjlojUCtH5sfZNmG/9/Kp4ds94ug/IPD/KuEYYuGiJ7VJ2OF ++8iRUi2Pny1uI6yhDtWMiX7R52K22pU2HjX0gAh+Nrkkt2jqF4KfXNi/H82zS9p5 +h6McHwSNbIqAJRFi/QEwS25OjY06nAA91Rm8yMbk4m6CdqWlgonyu969FTTX5XHw +ZtbQ590Ugs3UUZiDJMoSpjv2aaVB3ORdX67O6hdSc2EripKYP5I2cBG6r64hsJJu +HPZhzPfPY3NUSRCqO6RP/mZhKrenAd2TTylqvLSLGg44vJd3qcPb5BoxZ/RbMaOM +As8RSoUrwUJdL8c83YzE3SlnurF7A+BB6PGksJJM3+mvsrLgZobU5SdjMlhZnxGz +8xLApaE3b/AM0ADSI6nkuBvYkK7Ucklh4fF3CXhzrkF2MKuMrQHy1uMcKv+lm9dd +8/vPkjyC/zUl4DpvhwxmoR/7Dh4VFfSUlFQyAAaRxqVKxJVThQnlN7Bl3RHKhgQv +6fK5aVwnbhP9I3voNSFTuld8WfFR0AxXizd73JpjOXC5n6JEELfztlZ222JUHjww +dsx7pEYTl84ipgtag8gR+N8ymiRB716kM54JSWXrry9aVQjRWlLOHlDeAcINAnxP +MhSEmx4oaOOOxq1tMiB5 +=Wmhe +-----END PGP SIGNATURE----- + +--Apple-Mail=_1ED4908E-80B8-4F2A-B4A5-676D6BA5CE7E-- + |