+Return-Path: <achow101@gmail.com>

+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org

+ [172.17.192.35])

+ by mail.linuxfoundation.org (Postfix) with ESMTPS id B20B3416

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Fri, 28 Oct 2016 15:27:35 +0000 (UTC)

+X-Greylist: whitelisted by SQLgrey-1.7.6

+Received: from mail-qk0-f174.google.com (mail-qk0-f174.google.com

+ [209.85.220.174])

+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6522C1B9

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Fri, 28 Oct 2016 15:27:34 +0000 (UTC)

+Received: by mail-qk0-f174.google.com with SMTP id z190so90074768qkc.2

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Fri, 28 Oct 2016 08:27:34 -0700 (PDT)

+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;

+ h=subject:to:references:from:message-id:date:user-agent:mime-version

+ :in-reply-to; bh=IpE0wwnHJHX5OCA17YNYWqmj+J44vMVrFvLLYNsgnLI=;

+ b=X+ZjiF12OTg3WcxLTc8qEIAoXl4kC7zU8IUOWnm4bkjzWVyfC7EUHrdXqYI5babqdl

+ iv4LsP+YuSqC9PdI0xA5ZlxY9mtGkSY8GOgd80c3EhA/lVGmXLLpCjnTX45cgpe5qbwK

+ 1pHlYd1P8FzLx1uhjaHKvnmMeZzxyVtCwEroj5TGLgxQ8GKq7C4KyowAC4Xy7W8dwus8

+ lPsAe4cqkkj5r7fGYXaBsSldDW3b4APM8sPQ3IP6Gks3d9kr6zZRqonmkSZTaVB4MWD+

+ 26DERUsTwuqDHHuMPt1G7qV64RGk58XiAnlTd8tmoIYXGL+UGDQCisgWreqf+c6NhCcM

+ cD5w==

+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;

+ d=1e100.net; s=20130820;

+ h=x-gm-message-state:subject:to:references:from:message-id:date

+ :user-agent:mime-version:in-reply-to;

+ bh=IpE0wwnHJHX5OCA17YNYWqmj+J44vMVrFvLLYNsgnLI=;

+ b=kLDQKZu1/mjII+8cMvBsJCLR/3D3rR+7g2DfiUotQoTcTb9Z56qPpAT6+zuyQOWVDt

+ 5T80KagCcgo5qc9G8uyQMkyEZR2wPfAJf2R384X1y1hxydzbifKbn1hBtVnpK9k5ddIB

+ hmE/HQZ1TpqwKLBgm5Qxjx3og1vpWQ0vEsFOw8KOMY0MJ1xgtZzvbHooGYJH08/Mn2qo

+ w8Wtl1xQdVkq2JGu/cb6LWlhu1l5tFCLDALMbDjz1y/pEkrfPaMPoGtt82770pH93QAU

+ cIz9GBGxD9kvsKVunkSejf5e0TommEgIJ9bZEeqxW/ceiAgfxD7ZdbqWoO0yRYAySlpl

+ 0mnw==

+X-Gm-Message-State: ABUngvd1I/g5KgMaau+GGD0FD74iHPAbpzXs3Rzco4CUGKZHDJDIi4ajdit2jzhNPVej7Q==

+X-Received: by 10.55.104.208 with SMTP id d199mr11401164qkc.222.1477668453476;

+ Fri, 28 Oct 2016 08:27:33 -0700 (PDT)

+Received: from [10.108.208.39] ([206.196.187.145])

+ by smtp.gmail.com with ESMTPSA id u44sm6486616qtu.5.2016.10.28.08.27.33

+ (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);

+ Fri, 28 Oct 2016 08:27:33 -0700 (PDT)

+To: Andrew <onelineproof@gmail.com>,

+ Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>

+References: <CAL8tG=mfRHidipraCbG7m6V18khf_czWbe=zZN7F6=Ksdae8AQ@mail.gmail.com>

+From: Andrew C <achow101@gmail.com>

+Message-ID: <7991eb2d-015c-cedc-518c-988821a2d03f@gmail.com>

+Date: Fri, 28 Oct 2016 11:28:35 -0400

+User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101

+ Thunderbird/45.4.0

+MIME-Version: 1.0

+In-Reply-To: <CAL8tG=mfRHidipraCbG7m6V18khf_czWbe=zZN7F6=Ksdae8AQ@mail.gmail.com>

+Content-Type: multipart/alternative;

+ boundary="------------5E675C7DBE61E88FFA7CF6F5"

+X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,

+ DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,

+ HTML_MESSAGE, RCVD_IN_DNSWL_LOW,

+ RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1

+X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on

+ smtp1.linux-foundation.org

+Subject: Re: [bitcoin-dev] The Soft Fork Deception

+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: Fri, 28 Oct 2016 15:27:35 -0000

+

+This is a multi-part message in MIME format.

+--------------5E675C7DBE61E88FFA7CF6F5

+Content-Type: text/plain; charset=windows-1252

+Content-Transfer-Encoding: quoted-printable

+

+

+On 10/27/2016 11:38 AM, Andrew via bitcoin-dev wrote:

+> I have been reading recently through the history of soft forks

+> provided by Bitcoin Core:

+> https://bitcoin.stackexchange.com/questions/43538/where-can-i-find-a-re=

+cord-of-blockchain-soft-forks.

+>

+> It has led me to think that there is a deceiving notion that soft

+> forks do not force Bitcoin users to upgrade software. Yes, it's true

+> that the past soft forks still allow old nodes to accept blocks under

+> the tighter rules as valid, but what about miners who are still using

+> old software? What about users who want to make a transaction using

+> the old rules? Those people are no longer able to do those things. And

+> if they want to do those things, a hard fork will result.

+A soft fork means that a transaction using the old rules will still

+work. Look at segwit, you can still make the original style of

+transactions with P2PK, P2PKH, and P2SH outputs. There is nothing here

+to cause a hard fork.

+

+> Remember what happened when BIP 66 was activated? Luckily, it was

+> short lived, but this is just the beginning. If you keep tightening

+> the rules, you are building up more and more pressure for a split in

+> the network to occur. You can call this split a "hard fork" or just a

+> "fork", but it is dangerous either way, and it leads to basically the

+> creation of two coins when before we just had one, people instantly

+> lose value, and the trust in Bitcoin's store of value dies.

+BIP 66's hard fork was not due to the soft fork making transactions

+invalid. Rather it was because miners were not properly validating

+blocks before building on top of them. That fork was because a

+non-upgraded miner created a block invalid under the new rules and

+upgraded miners did not check the block and built on top of it. That

+invalid block was only invalid because the isSuperMajority mechanism

+specified that the new version number must be used otherwise the block

+was invalid, and that was what happened: the invalid block had the old

+version number. This is not an issue for BIP 9 Versionbits soft forks

+because no such rule exists.

+>

+> Obviously every one can debate about what should be the definition of

+> a soft fork, but whatever that is, I think it is unacceptable how

+> sloppily the past soft forks have been deployed.

+In what way have these forks been sloppily deployed? The fork caused by

+previous a soft forks (there was only one that caused that had an actual

+chain split issue) was due to the isSuperMajority mechanism which is not

+a good mechanism for deployment. It has been superseded by BIP 9

+Versionbits. Furthermore, that fork was not due to "sloppy deployment"

+by the devs but rather due to greedy miners who were SPV mining.

+> I can think of many ways in which we could have these new features

+> that the soft forks provided, but without forcing the new rules, and

+> simply making them features that can be used on an individual miner or

+> transaction signer basis. Is there a document from Bitcoin Core that

+> outlines the philosophy of soft forks and why it is acceptable to

+> force the tightening of rules and cause such risks? And please give me

+> another reason other than "it removes a few if statements from the code=

+".

+Can you explain what other risks you think there are with soft forks?

+>

+> Now that Segregated witness is scheduled to be deployed on November

+> 15, we should take a look at this "soft fork" as well. I like the idea

+> of Segregated Witness, but from conversations on Reddit and IRC, I see

+> people saying that this soft fork will be like the others: requiring a

+> hard fork in order to revert it. Is this true?

+If you are reading r/btc, you are doing something wrong.

+

+Like with all soft forks, the only way to revert them is by a hard fork.

+Soft forks make previously valid things invalid, hard forks make

+previously invalid things valid. In order to revert a soft fork which

+made something invalid, you need to hard fork to make it valid again.

+> I am getting conflicting messages by reading the BIP. It says that if

+> all transactions are non-segwit, then a node will validate the block

+> as before. But if we pass the threshhold (usually 95 % for 1000

+> blocks) will miners mining non-segwit blocks be ignored? This is not

+> good... I really think we should make it optional. Miners will have an

+> incentive to mine segwit blocks, since it allows for more transactions

+> per block, so why force them?

+No. This is incorrect. There is no requirement to include the witness

+commitment in the coinbase if no transactions in the block contain

+witnesses. Because transactions that contain witnesses are considered

+non-standard transactions by the old rules, if a miner who did not

+upgrade continues to follow those standardness rules, their blocks will

+not be invalid and they are not forced to upgrade.

+> What if we want to slightly modify the Segwit protocol in the future?

+> What if we want to replace segwit with something much different? We

+> will be forced to do a hard fork in order to do that.

+Not necessarily, it depends on the change. Most changes (such as

+sighashing, new opcodes, different scripts, etc.) can be done via

+another soft fork because segwit introduces script versioning. A new

+script version would be created with the necessary changes and that can

+be soft forked in.

+>

+> Now, we can't go back in time and fix the deployment of the soft

+> forks, but I do propose one clean way to fix things: Remove all the

+> previously "soft forked" rules for non segwit transactions, and

+> require them only for segwit transactions. But make segwit optional!

+> In addition to what I talked about above, this may also relieve some

+> tensions of people who are not comfortable with segwit and are

+> thinking of joining a hard fork like the Bitcoin Unlimited project.

+Segwit already is optional. If you don't want to use segwit, you don't

+have to. If you don't want to mine segwit blocks, you don't have to.

+

+As for removing all previously soft forked things, then you would be

+removing a ton of functionality, various fixes, and potentially break a

+large number of transactions that already exists but are not confirmed

+yet. This would require a hard fork.

+

+As for what is would be reverted, you would be reverting P2SH (multisig

+addresses, you still want those right?), OP_CLTV, OP_CSV, block height

+requirement in Coinbase, the value overflow incident, removal of

+dangerous opcodes, reduction of block size limit, etc. As you can see, a

+lot of functionality and various bug fixes would be lost be reverting

+every single soft fork.

+>

+> Unless people can give me a good explanation as to why we are

+> deploying soft forks in such forceful manner,

+As I have said throughout this response, soft forks are not deployed in

+a forceful manner which forces people to upgrade.

+> or Bitcoin Core accepts my proposal, then I will have no choice but to

+> create a new client (I'm thinking to call it Bitcoin Authentic), that

+> will be just as Bitcoin Core but will always follow the chain with the

+> most work regardless of whether soft fork rules are respected, and I

+> would put at least CHECKLOCKTIMEVERIFY as mandatory within segwit

+> transactions.

+Great, go ahead. Honestly, I don't think anyone cares about your

+"ultimatum". You are a random person on the internet.

+>

+> --=20

+> PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647

+>

+>

+> _______________________________________________

+> bitcoin-dev mailing list

+> bitcoin-dev@lists.linuxfoundation.org

+> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

+

+

+--------------5E675C7DBE61E88FFA7CF6F5

+Content-Type: text/html; charset=windows-1252

+Content-Transfer-Encoding: 8bit

+

+<html>

+ <head>

+ <meta content="text/html; charset=windows-1252"

+ http-equiv="Content-Type">

+ </head>

+ <body bgcolor="#FFFFFF" text="#000000">

+ <br>

+ <div class="moz-cite-prefix">On 10/27/2016 11:38 AM, Andrew via

+ bitcoin-dev wrote:<br>

+ </div>

+ <blockquote

+cite="mid:CAL8tG=mfRHidipraCbG7m6V18khf_czWbe=zZN7F6=Ksdae8AQ@mail.gmail.com"

+ type="cite">

+ <div dir="ltr">

+ <div>

+ <div>I have been reading recently through the history of soft

+ forks provided by Bitcoin Core: <a moz-do-not-send="true"

+href="https://bitcoin.stackexchange.com/questions/43538/where-can-i-find-a-record-of-blockchain-soft-forks">https://bitcoin.stackexchange.com/questions/43538/where-can-i-find-a-record-of-blockchain-soft-forks</a>.<br>

+ <br>

+ </div>

+ It has led me to think that there is a deceiving notion that

+ soft forks do not force Bitcoin users to upgrade software.

+ Yes, it's true that the past soft forks still allow old nodes

+ to accept blocks under the tighter rules as valid, but what

+ about miners who are still using old software? What about

+ users who want to make a transaction using the old rules?

+ Those people are no longer able to do those things. And if

+ they want to do those things, a hard fork will result.<br>

+ </div>

+ </div>

+ </blockquote>

+ A soft fork means that a transaction using the old rules will still

+ work. Look at segwit, you can still make the original style of

+ transactions with P2PK, P2PKH, and P2SH outputs. There is nothing

+ here to cause a hard fork.<br>

+ <br>

+ <blockquote

+cite="mid:CAL8tG=mfRHidipraCbG7m6V18khf_czWbe=zZN7F6=Ksdae8AQ@mail.gmail.com"

+ type="cite">

+ <div dir="ltr">

+ <div>Remember what happened when BIP 66 was activated? Luckily,

+ it was short lived, but this is just the beginning. If you

+ keep tightening the rules, you are building up more and more

+ pressure for a split in the network to occur. You can call

+ this split a "hard fork" or just a "fork", but it is dangerous

+ either way, and it leads to basically the creation of two

+ coins when before we just had one, people instantly lose

+ value, and the trust in Bitcoin's store of value dies.<br>

+ </div>

+ </div>

+ </blockquote>

+ BIP 66's hard fork was not due to the soft fork making transactions

+ invalid. Rather it was because miners were not properly validating

+ blocks before building on top of them. That fork was because a

+ non-upgraded miner created a block invalid under the new rules and

+ upgraded miners did not check the block and built on top of it. That

+ invalid block was only invalid because the isSuperMajority mechanism

+ specified that the new version number must be used otherwise the

+ block was invalid, and that was what happened: the invalid block had

+ the old version number. This is not an issue for BIP 9 Versionbits

+ soft forks because no such rule exists.<br>

+ <blockquote

+cite="mid:CAL8tG=mfRHidipraCbG7m6V18khf_czWbe=zZN7F6=Ksdae8AQ@mail.gmail.com"

+ type="cite">

+ <div dir="ltr">

+ <div><br>

+ </div>

+ Obviously every one can debate about what should be the

+ definition of a soft fork, but whatever that is, I think it is

+ unacceptable how sloppily the past soft forks have been

+ deployed. </div>

+ </blockquote>

+ In what way have these forks been sloppily deployed? The fork caused

+ by previous a soft forks (there was only one that caused that had an

+ actual chain split issue) was due to the isSuperMajority mechanism

+ which is not a good mechanism for deployment. It has been superseded

+ by BIP 9 Versionbits. Furthermore, that fork was not due to "sloppy

+ deployment" by the devs but rather due to greedy miners who were SPV

+ mining.<br>

+ <blockquote

+cite="mid:CAL8tG=mfRHidipraCbG7m6V18khf_czWbe=zZN7F6=Ksdae8AQ@mail.gmail.com"

+ type="cite">

+ <div dir="ltr">I can think of many ways in which we could have

+ these new features that the soft forks provided, but without

+ forcing the new rules, and simply making them features that can

+ be used on an individual miner or transaction signer basis. Is

+ there a document from Bitcoin Core that outlines the philosophy

+ of soft forks and why it is acceptable to force the tightening

+ of rules and cause such risks? And please give me another reason

+ other than "it removes a few if statements from the code".<br>

+ </div>

+ </blockquote>

+ Can you explain what other risks you think there are with soft

+ forks?<br>

+ <blockquote

+cite="mid:CAL8tG=mfRHidipraCbG7m6V18khf_czWbe=zZN7F6=Ksdae8AQ@mail.gmail.com"

+ type="cite">

+ <div dir="ltr">

+ <div>

+ <div>

+ <div>

+ <div>

+ <div><br>

+ </div>

+ <div>Now that Segregated witness is scheduled to be

+ deployed on November 15, we should take a look at this

+ "soft fork" as well. I like the idea of Segregated

+ Witness, but from conversations on Reddit and IRC, I

+ see people saying that this soft fork will be like the

+ others: requiring a hard fork in order to revert it.

+ Is this true? </div>

+ </div>

+ </div>

+ </div>

+ </div>

+ </div>

+ </blockquote>

+ If you are reading r/btc, you are doing something wrong.<br>

+ <br>

+ Like with all soft forks, the only way to revert them is by a hard

+ fork. Soft forks make previously valid things invalid, hard forks

+ make previously invalid things valid. In order to revert a soft fork

+ which made something invalid, you need to hard fork to make it valid

+ again.<br>

+ <blockquote

+cite="mid:CAL8tG=mfRHidipraCbG7m6V18khf_czWbe=zZN7F6=Ksdae8AQ@mail.gmail.com"

+ type="cite">

+ <div dir="ltr">

+ <div>

+ <div>

+ <div>

+ <div>

+ <div>I am getting conflicting messages by reading the

+ BIP. It says that if all transactions are non-segwit,

+ then a node will validate the block as before. But if

+ we pass the threshhold (usually 95 % for 1000 blocks)

+ will miners mining non-segwit blocks be ignored? This

+ is not good... I really think we should make it

+ optional. Miners will have an incentive to mine segwit

+ blocks, since it allows for more transactions per

+ block, so why force them? </div>

+ </div>

+ </div>

+ </div>

+ </div>

+ </div>

+ </blockquote>

+ No. This is incorrect. There is no requirement to include the

+ witness commitment in the coinbase if no transactions in the block

+ contain witnesses. Because transactions that contain witnesses are

+ considered non-standard transactions by the old rules, if a miner

+ who did not upgrade continues to follow those standardness rules,

+ their blocks will not be invalid and they are not forced to upgrade.<br>

+ <blockquote

+cite="mid:CAL8tG=mfRHidipraCbG7m6V18khf_czWbe=zZN7F6=Ksdae8AQ@mail.gmail.com"

+ type="cite">

+ <div dir="ltr">

+ <div>

+ <div>

+ <div>

+ <div>

+ <div>What if we want to slightly modify the Segwit

+ protocol in the future? What if we want to replace

+ segwit with something much different? We will be

+ forced to do a hard fork in order to do that.<br>

+ </div>

+ </div>

+ </div>

+ </div>

+ </div>

+ </div>

+ </blockquote>

+ Not necessarily, it depends on the change. Most changes (such as

+ sighashing, new opcodes, different scripts, etc.) can be done via

+ another soft fork because segwit introduces script versioning. A new

+ script version would be created with the necessary changes and that

+ can be soft forked in.<br>

+ <blockquote

+cite="mid:CAL8tG=mfRHidipraCbG7m6V18khf_czWbe=zZN7F6=Ksdae8AQ@mail.gmail.com"

+ type="cite">

+ <div dir="ltr">

+ <div>

+ <div>

+ <div>

+ <div>

+ <div><br>

+ </div>

+ <div>Now, we can't go back in time and fix the

+ deployment of the soft forks, but I do propose one

+ clean way to fix things: Remove all the previously

+ "soft forked" rules for non segwit transactions, and

+ require them only for segwit transactions. But make

+ segwit optional! In addition to what I talked about

+ above, this may also relieve some tensions of people

+ who are not comfortable with segwit and are thinking

+ of joining a hard fork like the Bitcoin Unlimited

+ project.<br>

+ </div>

+ </div>

+ </div>

+ </div>

+ </div>

+ </div>

+ </blockquote>

+ Segwit already is optional. If you don't want to use segwit, you

+ don't have to. If you don't want to mine segwit blocks, you don't

+ have to.<br>

+ <br>

+ As for removing all previously soft forked things, then you would be

+ removing a ton of functionality, various fixes, and potentially

+ break a large number of transactions that already exists but are not

+ confirmed yet. This would require a hard fork.<br>

+ <br>

+ As for what is would be reverted, you would be reverting P2SH

+ (multisig addresses, you still want those right?), OP_CLTV, OP_CSV,

+ block height requirement in Coinbase, the value overflow incident,

+ removal of dangerous opcodes, reduction of block size limit, etc. As

+ you can see, a lot of functionality and various bug fixes would be

+ lost be reverting every single soft fork.<br>

+ <blockquote

+cite="mid:CAL8tG=mfRHidipraCbG7m6V18khf_czWbe=zZN7F6=Ksdae8AQ@mail.gmail.com"

+ type="cite">

+ <div dir="ltr">

+ <div>

+ <div>

+ <div>

+ <div>

+ <div><br>

+ </div>

+ <div>Unless people can give me a good explanation as to

+ why we are deploying soft forks in such forceful

+ manner, </div>

+ </div>

+ </div>

+ </div>

+ </div>

+ </div>

+ </blockquote>

+ As I have said throughout this response, soft forks are not deployed

+ in a forceful manner which forces people to upgrade.<br>

+ <blockquote

+cite="mid:CAL8tG=mfRHidipraCbG7m6V18khf_czWbe=zZN7F6=Ksdae8AQ@mail.gmail.com"

+ type="cite">

+ <div dir="ltr">

+ <div>

+ <div>

+ <div>

+ <div>

+ <div>or Bitcoin Core accepts my proposal, then I will

+ have no choice but to create a new client (I'm

+ thinking to call it Bitcoin Authentic), that will be

+ just as Bitcoin Core but will always follow the chain

+ with the most work regardless of whether soft fork

+ rules are respected, and I would put at least

+ CHECKLOCKTIMEVERIFY as mandatory within segwit

+ transactions.<br clear="all">

+ </div>

+ </div>

+ </div>

+ </div>

+ </div>

+ </div>

+ </blockquote>

+ Great, go ahead. Honestly, I don't think anyone cares about your

+ "ultimatum". You are a random person on the internet.<br>

+ <blockquote

+cite="mid:CAL8tG=mfRHidipraCbG7m6V18khf_czWbe=zZN7F6=Ksdae8AQ@mail.gmail.com"

+ type="cite">

+ <div dir="ltr">

+ <div>

+ <div>

+ <div>

+ <div>

+ <div>

+ <div><br>

+ -- <br>

+ <div class="gmail_signature">PGP: B6AC 822C 451D

+ 6304 6A28 �49E9 7DB7 011C D53B 5647</div>

+ </div>

+ </div>

+ </div>

+ </div>

+ </div>

+ </div>

+ </div>

+ <br>

+ <fieldset class="mimeAttachmentHeader"></fieldset>

+ <br>

+ <pre wrap="">_______________________________________________

+bitcoin-dev mailing list

+<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>

+<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>

+</pre>

+ </blockquote>

+ <br>

+ </body>

+</html>

+

+--------------5E675C7DBE61E88FFA7CF6F5--

+