Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C1D8089C for ; Wed, 7 Jun 2017 05:20:56 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from homiemail-a38.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 26FFEAF for ; Wed, 7 Jun 2017 05:20:55 +0000 (UTC) Received: from homiemail-a38.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTP id 8EFD010AFB8; Tue, 6 Jun 2017 22:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=taoeffect.com; bh=sVv2Q/GYiVhBmp0wt JVpfx+IYYg=; b=nKGaFxymOoWrGt8uP7IkklHNawTFbAYVcqq7/L2To5w37dDDz JinlZORFdw4s8oyrGNtKzG1Jt0s70ndWi1L5nceGWHFFP6YO+z8Fc3rCzMMQNJJQ A/ST/lZ2mp3KOXT3h6DM3LNmC974vlLwuet0nJxXSR3cDrb9tJKvCwbIn8= Received: from [192.168.42.64] (184-23-255-227.fiber.dynamic.sonic.net [184.23.255.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: contact@taoeffect.com) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTPSA id 0B1AB10AFB5; Tue, 6 Jun 2017 22:20:53 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_0B064388-514E-4552-9F26-7FF7E720FA69"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tao Effect In-Reply-To: Date: Tue, 6 Jun 2017 22:20:52 -0700 X-Mao-Original-Outgoing-Id: 518505652.568632-18b1d1107604a18d7447e6ce63edab74 Message-Id: <0CDEF5A2-0BAF-46E4-8906-39D4724AF3F2@taoeffect.com> References: To: James Hilliard X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 07 Jun 2017 12:52:53 +0000 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] User Activated Soft Fork Split Protection X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 05:20:56 -0000 --Apple-Mail=_0B064388-514E-4552-9F26-7FF7E720FA69 Content-Type: multipart/alternative; boundary="Apple-Mail=_DE124293-3620-4B41-BE35-4A2CDABE7FD2" --Apple-Mail=_DE124293-3620-4B41-BE35-4A2CDABE7FD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii See thread on replay attacks for why activating regardless of threshold = is a bad idea [1]. BIP91 OTOH seems perfectly reasonable. 80% instead of 95% makes it more = difficult for miners to hold together in opposition to Core. It gives = Core more leverage in negotiations. If they don't activate with 80%, Core can release another BIP to reduce = it to 75%. Each threshold reduction makes it both more likely to succeed, but also = increases the likelihood of harm to the ecosystem. Cheers, Greg [1] = https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014497.h= tml = -- Please do not email me anything that you are not comfortable also = sharing with the NSA. > On Jun 6, 2017, at 6:54 PM, James Hilliard > wrote: >=20 > This is a BIP8 style soft fork so mandatory signalling will be active > after Aug 1st regardless. >=20 > On Tue, Jun 6, 2017 at 8:51 PM, Tao Effect > wrote: >> What is the probability that a 65% threshold is too low and can allow = a >> "surprise miner attack", whereby miners are kept offline before the >> deadline, and brought online immediately after, creating potential = havoc? >>=20 >> (Nit: "simple majority" usually refers to >50%, I think, might cause >> confusion.) >>=20 >> -Greg Slepak >>=20 >> -- >> Please do not email me anything that you are not comfortable also = sharing >> with the NSA. >>=20 >> On Jun 6, 2017, at 5:56 PM, James Hilliard via bitcoin-dev >> > wrote: >>=20 >> Due to the proposed calendar(https://segwit2x.github.io/ = ) for the >> SegWit2x agreement being too slow to activate SegWit mandatory >> signalling ahead of BIP148 using BIP91 I would like to propose = another >> option that miners can use to prevent a chain split ahead of the Aug >> 1st BIP148 activation date. >>=20 >> The splitprotection soft fork is essentially BIP91 but using BIP8 >> instead of BIP9 with a lower activation threshold and immediate >> mandatory signalling lock-in. This allows for a majority of miners to >> activate mandatory SegWit signalling and prevent a potential chain >> split ahead of BIP148 activation. >>=20 >> This BIP allows for miners to respond to market forces quickly ahead >> of BIP148 activation by signalling for splitprotection. Any miners >> already running BIP148 should be encouraged to use splitprotection. >>=20 >> 
>> BIP: splitprotection
>> Layer: Consensus (soft fork)
>> Title: User Activated Soft Fork Split Protection
>> Author: James Hilliard >
>> Comments-Summary: No comments yet.
>> Comments-URI:
>> Status: Draft
>> Type: Standards Track
>> Created: 2017-05-22
>> License: BSD-3-Clause
>>          CC0-1.0
>>
>>=20 >> =3D=3DAbstract=3D=3D >>=20 >> This document specifies a coordination mechanism for a simple = majority >> of miners to prevent a chain split ahead of BIP148 activation. >>=20 >> =3D=3DDefinitions=3D=3D >>=20 >> "existing segwit deployment" refer to the BIP9 "segwit" deployment >> using bit 1, between November 15th 2016 and November 15th 2017 to >> activate BIP141, BIP143 and BIP147. >>=20 >> =3D=3DMotivation=3D=3D >>=20 >> The biggest risk of BIP148 is an extended chain split, this BIP >> provides a way for a simple majority of miners to eliminate that = risk. >>=20 >> This BIP provides a way for a simple majority of miners to coordinate >> activation of the existing segwit deployment with less than 95% >> hashpower before BIP148 activation. Due to time constraints unless >> immediately deployed BIP91 will likely not be able to enforce >> mandatory signalling of segwit before the Aug 1st activation of >> BIP148. This BIP provides a method for rapid miner activation of >> SegWit mandatory signalling ahead of the BIP148 activation date. = Since >> the primary goal of this BIP is to reduce the chance of an extended >> chain split as much as possible we activate using a simple miner >> majority of 65% over a 504 block interval rather than a higher >> percentage. This BIP also allows miners to signal their intention to >> run BIP148 in order to prevent a chain split. >>=20 >> =3D=3DSpecification=3D=3D >>=20 >> While this BIP is active, all blocks must set the nVersion header top >> 3 bits to 001 together with bit field (1<<1) (according to the >> existing segwit deployment). Blocks that do not signal as required >> will be rejected. >>=20 >> =3D=3DDeployment=3D=3D >>=20 >> This BIP will be deployed by "version bits" with a 65%(this can be >> adjusted if desired) activation threshold BIP9 with the name >> "splitprotecion" and using bit 2. >>=20 >> This BIP starts immediately and is a BIP8 style soft fork since >> mandatory signalling will start on midnight August 1st 2017 (epoch >> time 1501545600) regardless of whether or not this BIP has reached = its >> own signalling threshold. This BIP will cease to be active when = segwit >> is locked-in. >>=20 >> =3D=3D=3D Reference implementation =3D=3D=3D >>=20 >> 
>> // Check if Segregated Witness is Locked In
>> bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
>> Consensus::Params& params)
>> {
>>   LOCK(cs_main);
>>   return (VersionBitsState(pindexPrev, params,
>> Consensus::DEPLOYMENT_SEGWIT, versionbitscache) =3D=3D
>> THRESHOLD_LOCKED_IN);
>> }
>>=20
>> // SPLITPROTECTION mandatory segwit signalling.
>> if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
>> Consensus::DEPLOYMENT_SPLITPROTECTION, versionbitscache) =3D=3D
>> THRESHOLD_LOCKED_IN &&
>>    !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
>> // Segwit is not locked in
>>    !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
>> and is not active.
>> {
>>   bool fVersionBits =3D (pindex->nVersion & VERSIONBITS_TOP_MASK) =3D=3D=

>> VERSIONBITS_TOP_BITS;
>>   bool fSegbit =3D (pindex->nVersion &
>> VersionBitsMask(chainparams.GetConsensus(),
>> Consensus::DEPLOYMENT_SEGWIT)) !=3D 0;
>>   if (!(fVersionBits && fSegbit)) {
>>       return state.DoS(0, error("ConnectBlock(): relayed block must
>> signal for segwit, please upgrade"), REJECT_INVALID, =
"bad-no-segwit");
>>   }
>> }
>>=20
>> // BIP148 mandatory segwit signalling.
>> int64_t nMedianTimePast =3D pindex->GetMedianTimePast();
>> if ( (nMedianTimePast >=3D 1501545600) &&  // Tue 01 Aug 2017 =
00:00:00 UTC
>>    (nMedianTimePast <=3D 1510704000) &&  // Wed 15 Nov 2017 00:00:00 =
UTC
>>    (!IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
>> // Segwit is not locked in
>>     !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) )
>> // and is not active.
>> {
>>   bool fVersionBits =3D (pindex->nVersion & VERSIONBITS_TOP_MASK) =3D=3D=

>> VERSIONBITS_TOP_BITS;
>>   bool fSegbit =3D (pindex->nVersion &
>> VersionBitsMask(chainparams.GetConsensus(),
>> Consensus::DEPLOYMENT_SEGWIT)) !=3D 0;
>>   if (!(fVersionBits && fSegbit)) {
>>       return state.DoS(0, error("ConnectBlock(): relayed block must
>> signal for segwit, please upgrade"), REJECT_INVALID, =
"bad-no-segwit");
>>   }
>> }
>>
>>=20 >> = https://github.com/bitcoin/bitcoin/compare/0.14...jameshilliard:splitprote= ction-v0.14.1 = >>=20 >> =3D=3DBackwards Compatibility=3D=3D >>=20 >> This deployment is compatible with the existing "segwit" bit 1 >> deployment scheduled between midnight November 15th, 2016 and = midnight >> November 15th, 2017. This deployment is also compatible with the >> existing BIP148 deployment. This BIP is compatible with BIP91 only if >> BIP91 activates before it and before BIP148. Miners will need to >> upgrade their nodes to support splitprotection otherwise they may >> build on top of an invalid block. While this bip is active users >> should either upgrade to splitprotection or wait for additional >> confirmations when accepting payments. >>=20 >> =3D=3DRationale=3D=3D >>=20 >> Historically we have used IsSuperMajority() to activate soft forks >> such as BIP66 which has a mandatory signalling requirement for miners >> once activated, this ensures that miners are aware of new rules being >> enforced. This technique can be leveraged to lower the signalling >> threshold of a soft fork while it is in the process of being deployed >> in a backwards compatible way. We also use a BIP8 style timeout to >> ensure that this BIP is compatible with BIP148 and that BIP148 >> compatible mandatory signalling activates regardless of miner >> signalling levels. >>=20 >> By orphaning non-signalling blocks during the BIP9 bit 1 "segwit" >> deployment, this BIP can cause the existing "segwit" deployment to >> activate without needing to release a new deployment. As we approach >> BIP148 activation it may be desirable for a majority of miners to = have >> a method that will ensure that there is no chain split. >>=20 >> =3D=3DReferences=3D=3D >>=20 >> = *[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/01371= 4.html >> Mailing list discussion] >> = *[https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283 >> P2SH flag day activation] >> *[[bip-0009.mediawiki|BIP9 Version bits with timeout and delay]] >> *[[bip-0016.mediawiki|BIP16 Pay to Script Hash]] >> *[[bip-0091.mediawiki|BIP91 Reduced threshold Segwit MASF]] >> *[[bip-0141.mediawiki|BIP141 Segregated Witness (Consensus layer)]] >> *[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for >> Version 0 Witness Program]] >> *[[bip-0147.mediawiki|BIP147 Dealing with dummy stack element = malleability]] >> *[[bip-0148.mediawiki|BIP148 Mandatory activation of segwit = deployment]] >> *[[bip-0149.mediawiki|BIP149 Segregated Witness (second deployment)]] >> *[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segwit = benefits] >>=20 >> =3D=3DCopyright=3D=3D >>=20 >> This document is dual licensed as BSD 3-clause, and Creative Commons >> CC0 1.0 Universal. >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>=20 >>=20 --Apple-Mail=_DE124293-3620-4B41-BE35-4A2CDABE7FD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
See thread on replay attacks for why = activating regardless of threshold is a bad idea [1].

BIP91 OTOH seems = perfectly reasonable. 80% instead of 95% makes it more difficult for = miners to hold together in opposition to Core. It gives Core more = leverage in negotiations.

If they don't activate with 80%, Core can release another BIP = to reduce it to 75%.

Each threshold reduction makes it both more likely to = succeed, but also increases the likelihood of harm to the = ecosystem.

Cheers,
Greg

[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Ju= ne/014497.html

--
Please do not email me anything that you are not = comfortable also sharing with the NSA.

On Jun 6, 2017, at 6:54 PM, James Hilliard <james.hilliard1@gmail.com> wrote:

This = is a BIP8 style soft fork so mandatory signalling will be active
after Aug 1st regardless.

On = Tue, Jun 6, 2017 at 8:51 PM, Tao Effect <contact@taoeffect.com> wrote:
What is the probability that a 65% threshold is = too low and can allow a
"surprise miner attack", whereby = miners are kept offline before the
deadline, and brought = online immediately after, creating potential havoc?

(Nit: "simple majority" usually refers to >50%, I think, = might cause
confusion.)

-Greg = Slepak

--
Please do not email = me anything that you are not comfortable also sharing
with = the NSA.

On Jun 6, 2017, at 5:56 PM, James = Hilliard via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:

Due to the proposed calendar(https://segwit2x.github.io/) for the
SegWit2x= agreement being too slow to activate SegWit mandatory
signalling ahead of BIP148 using BIP91 I would like to = propose another
option that miners can use to prevent a = chain split ahead of the Aug
1st BIP148 activation = date.

The splitprotection soft fork is = essentially BIP91 but using BIP8
instead of BIP9 with a = lower activation threshold and immediate
mandatory = signalling lock-in. This allows for a majority of miners to
activate mandatory SegWit signalling and prevent a potential = chain
split ahead of BIP148 activation.

This BIP allows for miners to respond to market forces = quickly ahead
of BIP148 activation by signalling for = splitprotection. Any miners
already running BIP148 should = be encouraged to use splitprotection.

<pre>
BIP: splitprotection
= Layer: Consensus (soft fork)
Title: User Activated Soft = Fork Split Protection
Author: James Hilliard <james.hilliard1@gmail.com>
= Comments-Summary: No comments yet.
Comments-URI:
Status: Draft
Type: Standards Track
Created: 2017-05-22
License: BSD-3-Clause
=          CC0-1.0
</pre>

=3D=3DAbstract=3D=3D<= br class=3D"">
This document specifies a coordination = mechanism for a simple majority
of miners to prevent a = chain split ahead of BIP148 activation.

=3D=3DDefinitions=3D=3D

"existing = segwit deployment" refer to the BIP9 "segwit" deployment
using bit 1, between November 15th 2016 and November 15th = 2017 to
activate BIP141, BIP143 and BIP147.

=3D=3DMotivation=3D=3D

The biggest risk of BIP148 is an extended chain split, this = BIP
provides a way for a simple majority of miners to = eliminate that risk.

This BIP provides a = way for a simple majority of miners to coordinate
activation= of the existing segwit deployment with less than 95%
hashpower before BIP148 activation. Due to time constraints = unless
immediately deployed BIP91 will likely not be able = to enforce
mandatory signalling of segwit before the Aug = 1st activation of
BIP148. This BIP provides a method for = rapid miner activation of
SegWit mandatory signalling = ahead of the BIP148 activation date. Since
the primary = goal of this BIP is to reduce the chance of an extended
chain split as much as possible we activate using a simple = miner
majority of 65% over a 504 block interval rather = than a higher
percentage. This BIP also allows miners to = signal their intention to
run BIP148 in order to prevent a = chain split.

=3D=3DSpecification=3D=3D

While this BIP is active, all blocks must set = the nVersion header top
3 bits to 001 together with bit = field (1<<1) (according to the
existing segwit = deployment). Blocks that do not signal as required
will be = rejected.

=3D=3DDeployment=3D=3D

This BIP will be deployed by "version bits" = with a 65%(this can be
adjusted if desired) activation = threshold BIP9 with the name
"splitprotecion" and using = bit 2.

This BIP starts immediately and is a = BIP8 style soft fork since
mandatory signalling will start = on midnight August 1st 2017 (epoch
time 1501545600) = regardless of whether or not this BIP has reached its
own = signalling threshold. This BIP will cease to be active when segwit
is locked-in.

=3D=3D=3D = Reference implementation =3D=3D=3D

<pre>
// Check if Segregated Witness is = Locked In
bool IsWitnessLockedIn(const CBlockIndex* = pindexPrev, const
Consensus::Params& params)
{
  LOCK(cs_main);
=   return (VersionBitsState(pindexPrev, params,
Consensus::DEPLOYMENT_SEGWIT, versionbitscache) =3D=3D
THRESHOLD_LOCKED_IN);
}

// SPLITPROTECTION mandatory segwit signalling.
if ( VersionBitsState(pindex->pprev, = chainparams.GetConsensus(),
Consensus::DEPLOYMENT_SPLITPROTECTION, versionbitscache) = =3D=3D
THRESHOLD_LOCKED_IN &&
=    !IsWitnessLockedIn(pindex->pprev, = chainparams.GetConsensus()) &&
// Segwit is not = locked in
=    !IsWitnessEnabled(pindex->pprev, = chainparams.GetConsensus()) ) //
and is not active.
{
  bool fVersionBits =3D = (pindex->nVersion & VERSIONBITS_TOP_MASK) =3D=3D
VERSIONBITS_TOP_BITS;
  bool fSegbit = =3D (pindex->nVersion &
VersionBitsMask(chainparams.GetConsensus(),
Consensus::DEPLOYMENT_SEGWIT)) !=3D 0;
=   if (!(fVersionBits && fSegbit)) {
=       return state.DoS(0, = error("ConnectBlock(): relayed block must
signal for = segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
=   }
}

// BIP148 = mandatory segwit signalling.
int64_t nMedianTimePast =3D = pindex->GetMedianTimePast();
if ( (nMedianTimePast = >=3D 1501545600) &&  // Tue 01 Aug 2017 00:00:00 UTC
   (nMedianTimePast <=3D 1510704000) = &&  // Wed 15 Nov 2017 00:00:00 UTC
=    (!IsWitnessLockedIn(pindex->pprev, = chainparams.GetConsensus()) &&
// Segwit is not = locked in
=     !IsWitnessEnabled(pindex->pprev, = chainparams.GetConsensus())) )
// and is not active.
{
  bool fVersionBits =3D = (pindex->nVersion & VERSIONBITS_TOP_MASK) =3D=3D
VERSIONBITS_TOP_BITS;
  bool fSegbit = =3D (pindex->nVersion &
VersionBitsMask(chainparams.GetConsensus(),
Consensus::DEPLOYMENT_SEGWIT)) !=3D 0;
=   if (!(fVersionBits && fSegbit)) {
=       return state.DoS(0, = error("ConnectBlock(): relayed block must
signal for = segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
=   }
}
</pre>

https://github.com/bitcoin/bitcoin/compare/0.14...jameshilliard= :splitprotection-v0.14.1

=3D=3DBackwards = Compatibility=3D=3D

This deployment is = compatible with the existing "segwit" bit 1
deployment = scheduled between midnight November 15th, 2016 and midnight
November 15th, 2017. This deployment is also compatible with = the
existing BIP148 deployment. This BIP is compatible = with BIP91 only if
BIP91 activates before it and before = BIP148. Miners will need to
upgrade their nodes to support = splitprotection otherwise they may
build on top of an = invalid block. While this bip is active users
should = either upgrade to splitprotection or wait for additional
confirmations when accepting payments.

=3D=3DRationale=3D=3D

Historically= we have used IsSuperMajority() to activate soft forks
such = as BIP66 which has a mandatory signalling requirement for miners
once activated, this ensures that miners are aware of new = rules being
enforced. This technique can be leveraged to = lower the signalling
threshold of a soft fork while it is = in the process of being deployed
in a backwards compatible = way. We also use a BIP8 style timeout to
ensure that this = BIP is compatible with BIP148 and that BIP148
compatible = mandatory signalling activates regardless of miner
signalling levels.

By orphaning = non-signalling blocks during the BIP9 bit 1 "segwit"
deployment, this BIP can cause the existing "segwit" = deployment to
activate without needing to release a new = deployment. As we approach
BIP148 activation it may be = desirable for a majority of miners to have
a method that = will ensure that there is no chain split.

=3D=3DReferences=3D=3D

*[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Ma= rch/013714.html
Mailing list discussion]
*[https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L12= 81-L1283
P2SH flag day activation]
*[[bip-0009.mediawiki|BIP9 Version bits with timeout and = delay]]
*[[bip-0016.mediawiki|BIP16 Pay to Script = Hash]]
*[[bip-0091.mediawiki|BIP91 Reduced threshold = Segwit MASF]]
*[[bip-0141.mediawiki|BIP141 Segregated = Witness (Consensus layer)]]
*[[bip-0143.mediawiki|BIP143 = Transaction Signature Verification for
Version 0 Witness = Program]]
*[[bip-0147.mediawiki|BIP147 Dealing with dummy = stack element malleability]]
*[[bip-0148.mediawiki|BIP148 = Mandatory activation of segwit deployment]]
*[[bip-0149.mediawiki|BIP149 Segregated Witness (second = deployment)]]
*[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segwit = benefits]

=3D=3DCopyright=3D=3D

This document is dual licensed as BSD = 3-clause, and Creative Commons
CC0 1.0 Universal.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= br class=3D"">


= --Apple-Mail=_DE124293-3620-4B41-BE35-4A2CDABE7FD2-- --Apple-Mail=_0B064388-514E-4552-9F26-7FF7E720FA69 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZN400AAoJEOxnICvpCVJHFL0P/3vSGw0NYME7QTK8KfBDbhEo 8D5Rf5al2jWh6q8UA2l7ZqmqPoaoIs7Vut/FFIs6AQ/d6oKIzI0VMyU4v1hTMkIT 5JH+HcLNhNcGae3QqGxqMNYXRtcFB3PRaQyXx0Arz78kCsh8SzLI+r2YgQgh9wrX 1klV7WdvriDTTTWEEyM04maXxCWgqwYFL7Vn7iqYCQhAhZ/X5jIRWgh6zIWer7ka zoj68gvrZTbICaBy9GjYINWHhOr/XsrykIA21A0Urptb2htV4DQ//pORLYqutqBE 1yJ34ARxFj6efBoytCqYAq2ltui/JxXBrK2h++IRa0dKRhWMobfn6QvTL22tWJme 5mlxvIKlANwiGrueQVyVttBtyRFandYtdLIJ9jd7K1J0VcrcB3HdQlVjLXYSXdgC w3GBqTv0867gH4A5K+4HQuXMSOH3ukXpMWzpLnzb7HdVBMb2Oaujv4Eu3X073A+4 65684LunYm/JlJxxTj5Otw59/kXbjVou0LifpE8nuYFEfeMPB0GTdQXezb2kG9hW m4Fd2aTv/kGoVaPz3d6sGuvolaM62vuTg5jLuL0fg0aA6IgQsGtJylGYHwq/luX6 RbFMZI4X9IpMEGnjcqRqdmelB9r4bo9DZ7YVTtxJ1Fe6Xv9+iwgO6Q5AZe+/7CsO ZWMAkfbn/+9y1IKhhvLz =jzWl -----END PGP SIGNATURE----- --Apple-Mail=_0B064388-514E-4552-9F26-7FF7E720FA69--