path: root/8e/ede7ba1adc593b1cbbdf7ebf7a4f97b932a2f4

Return-Path: <willtech@live.com.au>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 7127BE8E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  6 Sep 2018 08:48:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from APC01-SG2-obe.outbound.protection.outlook.com
	(mail-oln040092253066.outbound.protection.outlook.com [40.92.253.66])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CE02B2D5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  6 Sep 2018 08:48:37 +0000 (UTC)
Received: from SG2APC01FT022.eop-APC01.prod.protection.outlook.com
	(10.152.250.52) by SG2APC01HT118.eop-APC01.prod.protection.outlook.com
	(10.152.251.82) with Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.1122.11;
	Thu, 6 Sep 2018 08:48:34 +0000
Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM (10.152.250.51) by
	SG2APC01FT022.mail.protection.outlook.com (10.152.250.205) with
	Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.1122.11 via
	Frontend Transport; Thu, 6 Sep 2018 08:48:34 +0000
Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM
	([fe80::8062:43b6:2a5f:cfb0]) by PS2P216MB0179.KORP216.PROD.OUTLOOK.COM
	([fe80::8062:43b6:2a5f:cfb0%3]) with mapi id 15.20.1101.019;
	Thu, 6 Sep 2018 08:48:34 +0000
From: Damian Williamson <willtech@live.com.au>
To: Ruben Somsen <rsomsen@gmail.com>, Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: [bitcoin-dev] Guiding transaction fees towards a more censorship
	resistant outcome
Thread-Index: AQHUQ951UGEqy5M5QEStboifcof5I6Ti9Lw0
Date: Thu, 6 Sep 2018 08:48:34 +0000
Message-ID: <PS2P216MB0179E804329D495A4EE6F4EC9D010@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
References: <CAPv7TjbnsqHwW=Oj7n_WJFR4vp1ND78NgV0=Ftj5doNuKOxLCg@mail.gmail.com>
In-Reply-To: <CAPv7TjbnsqHwW=Oj7n_WJFR4vp1ND78NgV0=Ftj5doNuKOxLCg@mail.gmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-AU
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-incomingtopheadermarker: OriginalChecksum:9BE196934DF214313433ED456E2E51B7158925274FE0E88418CEB77F2526D612;
	UpperCasedChecksum:06ECEDE1795DEEBD3F32EACC88B28E12FFAFB441910BDC34610ADDAD7EFE48AE;
	SizeAsReceived:7182; Count:46
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [9MXL2T5aB9LHv8w26BV2fR1TNIChSku0]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SG2APC01HT118;
	6:/l71vqE9wcxvPmZ7WG6xzZlF+mDg+WEPPhF6sM2LUF1H7faxOmL0hwTlM1S5ggQJetNvHkjQYr8ZKG9IKs0wE28G1BAlzGMorDF2y0fFR+zG/gErXWtzGBSGvHJN/zqoentSFjRwY+cIJRTdThAM1wl9LtZGuwjFJ2zExng8CeM7c0fey8smN1L12+cZmqmyVTfHwEmsgnJsO3ipe5nUJlCm/ozqMrA0d3EOnH3PEy2z2t49bwAsRJjUXQUk167m+mKOZbhJ0FmmNEH1pB2H+7mfQoEWwvvGPYwlSIxeywGOK50P41Hl5juEAmSATkZVdPsJw/xW9cnzRhrJv2ZkZlBKr+5uoXUG6gkOYgtHkb2LG4/L7SJV5Z/lJtQN61YdQ5YC8FPgm+ofIimvjN2UA1VFlRLPo22027wLsO7dQ4ldPbkgSbTx57Jo0bpDFUvhMWD1o3ROstJ+Bsix7Tw7Ow==;
	5:Qujf3YNeL8ylBcadCFxqI73kBnIfhGHYaIMX5fY9Rfl0Ee1B9oqvBN2dtDi03I9+5Ujs8VDmjrHn+4xk9ZfpX/IzDHwsqpv42aITTmf4a5mI0MTtuyNT3SF++GgMkd5oKgOe316SSnmcXVfhNQYd/32b2jiuQZ65YKrva1AzOCo=;
	7:efNLzeeJyb8sWFFxCAKUrA+rqhmHXndYN2/5BudKDPFIUYZsMrrNrPVVSX9ZJ7S8DSNNCf6xe239L/UljqeEHIeEwvFzn2INYfctUKh1k94+y0miKGloTLIleKNuAbOKYhY5mtGlbH5PVuLP/fMvPPi8LB1bd4DMjB/BNm0OUK/bqETCLb0T+2bO8rDVXjQDahR0g2m6rnuDZKJ4IctV8Gp2yNPX4LVwSE7P71M4dbbtdQT/aLEcjWyZCDLeEBJ6
x-incomingheadercount: 46
x-eopattributedmessage: 0
x-microsoft-antispam: BCL:0; PCL:0;
	RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125500)(1603101475)(1701031045);
	SRVR:SG2APC01HT118; 
x-ms-traffictypediagnostic: SG2APC01HT118:
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058);
	SRVR:SG2APC01HT118; BCL:0; PCL:0; RULEID:; SRVR:SG2APC01HT118; 
x-forefront-prvs: 0787459938
x-forefront-antispam-report: SFV:NSPM;
	SFS:(7070007)(189003)(199004)(106356001)(14444005)(5024004)(256004)(446003)(6606003)(11346002)(82202002)(105586002)(551934003)(45080400002)(56003)(5250100002)(74316002)(86362001)(575784001)(347745004)(25786009)(97736004)(966005)(104016004)(74482002)(68736007)(14454004)(606006)(39060400002)(6246003)(76176011)(99286004)(5660300001)(66574006)(6436002)(6506007)(16799955002)(110136005)(476003)(2900100001)(486006)(81156014)(6346003)(102836004)(55016002)(8936002)(229853002)(26005)(54896002)(6306002)(7696005)(19627405001)(9686003)(236005)(33656002);
	DIR:OUT; SFP:1901; SCL:1; SRVR:SG2APC01HT118;
	H:PS2P216MB0179.KORP216.PROD.OUTLOOK.COM; FPR:; SPF:None;
	PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: live.com.au does not designate
	permitted sender hosts)
authentication-results: spf=none (sender IP is )
	smtp.mailfrom=willtech@live.com.au; 
x-microsoft-antispam-message-info: hTfVMkDxcAdqz4vYw5A9b27Vi4x31bdNVybzCQCdoRkdvXBY3qhSiJpm5Q+MwvVRgW2aS9MO5MnkEqtTmdqUhRRCaLAoiZdYW5e+yrRADiUbSIk25gj4G/xQvGhorwIyrPbRg9KSTHH9W+ewDu8Rbw09BGFZXEko69jwwCxSi7EU0cA+lDYkbEdu0mph9Mbcvz1R0WAPQRZ5Opf6dFitEo3GIvhup7Rq4w+MWz+qwV8=
Content-Type: multipart/alternative;
	boundary="_000_PS2P216MB0179E804329D495A4EE6F4EC9D010PS2P216MB0179KORP_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: c001924d-3e68-4f40-89c2-901a49278da7
X-MS-Exchange-CrossTenant-Network-Message-Id: b41ef793-bd4d-474d-484b-08d613d587c8
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: c001924d-3e68-4f40-89c2-901a49278da7
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Sep 2018 08:48:34.5824 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT118
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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: Thu, 06 Sep 2018 13:07:43 +0000
Subject: Re: [bitcoin-dev] Guiding transaction fees towards a more
	censorship	resistant outcome
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: Thu, 06 Sep 2018 08:48:39 -0000

--_000_PS2P216MB0179E804329D495A4EE6F4EC9D010PS2P216MB0179KORP_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Humour me please,


Where you say "create transactions which are only valid if they are mined o=
n top of a specific block." - in practice, does that usually means at any h=
eight above a specific block?

________________________________
From: bitcoin-dev-bounces@lists.linuxfoundation.org <bitcoin-dev-bounces@li=
sts.linuxfoundation.org> on behalf of Ruben Somsen via bitcoin-dev <bitcoin=
-dev@lists.linuxfoundation.org>
Sent: Sunday, 2 September 2018 3:26:54 AM
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] Guiding transaction fees towards a more censorship r=
esistant outcome

When a user creates a transaction with a fee attached, they are
incentivizing miners to add this transaction to the blockchain. The
task is usually not very specific -- as long as it ends up in a valid
chain with the most Proof-of-Work, miners get paid. The payment is an
incentive for miners to act in the way that users desire.

To the user, there=92s an individual benefit: their transaction gets
added. To the network, there=92s a shared benefit: all fees add to the
security of other transactions in the chain. Miners can choose to
ignore the incentives, but they would be leaving money on the table
(and eventually get replaced by more competitive miners).

Transactions from Bitcoin Core are slightly more specific about what
they ask miners to do. Every transaction is only valid at a block
height that is one higher than the last block. This incentivizes
miners to build on top of the last block, instead of going back and
reorganizing the blockchain. This is especially important in a future
scenario where the fee reward is larger than the block reward.

BIP 115* by Luke-jr is even more specific. It enables users to create
transactions which are only valid if they are mined on top of a
specific block. While originally designed as a form of replay
protection, it actually serves as a deterrent for miners to reorganize
the blockchain. If they orphan a block, it will invalidate
transactions that demanded the inclusion of the orphaned block. This
increases the cost of intentionally reorganizing the blockchain.

Coinjoin**, the act of combining payments of multiple users into a
single transaction, can be seen as yet another method for users to be
more specific. The fate of their payments are now intertwined with
that of others. If miners wish to censor a single payment, they have
to reject the entire transaction, and the associated fee amount.
Techniques like mimblewimble simplify this process, by making coinjoin
non-interactive.

This brings us to a theoretical scenario where:

- every block contains only a single coinjoin transaction
- the validity of this transaction depends on the inclusion of a
specific previous block
- the block reward is negligible compared to transaction fees

In this scenario, if miners wish to undo a specific transaction that
happened two blocks ago, they would have to create three empty blocks
(receiving negligible compensation) in order to overtake the longest
chain. And even then, users can still refuse to let their new
transactions be mined on top of the empty blocks, disincentivizing
such behavior completely.

While not easy to achieve in practice (e.g. resolving natural forks
becomes more complicated), it demonstrates that users can become more
empowered than they are today, benefitting censorship resistance***.
It is this line of thinking that I wish to convey. Perhaps it may
inspire further ideas in this direction.

-- Ruben Somsen


* BIP 115: https://apc01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2=
F%2Fgithub.com%2Fbitcoin%2Fbips%2Fblob%2Fmaster%2Fbip-0115.mediawiki&amp;da=
ta=3D02%7C01%7C%7C48403f77efc14613e89b08d611f5980c%7C84df9e7fe9f640afb435aa=
aaaaaaaaaa%7C1%7C0%7C636716143839246019&amp;sdata=3Dreq4KYOcztXLAG%2Fu4Rrmh=
LREGBF28JNTe45pO86kRd4%3D&amp;reserved=3D0

** Coinjoin: https://apc01.safelinks.protection.outlook.com/?url=3Dhttps%3A=
%2F%2Fbitcointalk.org%2Findex.php%3Ftopic%3D279249.0&amp;data=3D02%7C01%7C%=
7C48403f77efc14613e89b08d611f5980c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7=
C0%7C636716143839246019&amp;sdata=3Dd%2B06jxrKubWhLwoInFEgo8eHvI9f1j74QN8WH=
7xrVos%3D&amp;reserved=3D0

*** Risk sharing principle:
https://apc01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.=
com%2Flibbitcoin%2Flibbitcoin%2Fwiki%2FRisk-Sharing-Principle&amp;data=3D02=
%7C01%7C%7C48403f77efc14613e89b08d611f5980c%7C84df9e7fe9f640afb435aaaaaaaaa=
aaa%7C1%7C0%7C636716143839246019&amp;sdata=3DNA3HxqI5PnuyaI9hyCaw0rcaFsrhD%=
2FXQB8biWJXej8g%3D&amp;reserved=3D0
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://apc01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Flists.l=
inuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-dev&amp;data=3D02%7C01%7C=
%7C48403f77efc14613e89b08d611f5980c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%=
7C0%7C636716143839246019&amp;sdata=3D9P7UetPmKWngjgjNPE0%2BAMgdzuL2DgqBLoLt=
i82f23M%3D&amp;reserved=3D0

--_000_PS2P216MB0179E804329D495A4EE6F4EC9D010PS2P216MB0179KORP_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
<style type=3D"text/css" style=3D"display:none;"><!-- P {margin-top:0;margi=
n-bottom:0;} --></style>
</head>
<body dir=3D"ltr">
<div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font=
-family:Calibri,Helvetica,sans-serif;" dir=3D"ltr">
<p style=3D"margin-top:0;margin-bottom:0">Humour me please,</p>
<p style=3D"margin-top:0;margin-bottom:0"><br>
</p>
<p style=3D"margin-top:0;margin-bottom:0">Where you say &quot;<font size=3D=
"2"><span style=3D"font-size:11pt;">create transactions which are only vali=
d if they are mined on top of a specific block.</span></font>&quot; - in pr=
actice, does that usually means at any height above
 a specific block?</p>
</div>
<hr style=3D"display:inline-block;width:98%" tabindex=3D"-1">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st=
yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b> bitcoin-dev-bounces@l=
ists.linuxfoundation.org &lt;bitcoin-dev-bounces@lists.linuxfoundation.org&=
gt; on behalf of Ruben Somsen via bitcoin-dev &lt;bitcoin-dev@lists.linuxfo=
undation.org&gt;<br>
<b>Sent:</b> Sunday, 2 September 2018 3:26:54 AM<br>
<b>To:</b> bitcoin-dev@lists.linuxfoundation.org<br>
<b>Subject:</b> [bitcoin-dev] Guiding transaction fees towards a more censo=
rship resistant outcome</font>
<div>&nbsp;</div>
</div>
<div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt;=
">
<div class=3D"PlainText">When a user creates a transaction with a fee attac=
hed, they are<br>
incentivizing miners to add this transaction to the blockchain. The<br>
task is usually not very specific -- as long as it ends up in a valid<br>
chain with the most Proof-of-Work, miners get paid. The payment is an<br>
incentive for miners to act in the way that users desire.<br>
<br>
To the user, there=92s an individual benefit: their transaction gets<br>
added. To the network, there=92s a shared benefit: all fees add to the<br>
security of other transactions in the chain. Miners can choose to<br>
ignore the incentives, but they would be leaving money on the table<br>
(and eventually get replaced by more competitive miners).<br>
<br>
Transactions from Bitcoin Core are slightly more specific about what<br>
they ask miners to do. Every transaction is only valid at a block<br>
height that is one higher than the last block. This incentivizes<br>
miners to build on top of the last block, instead of going back and<br>
reorganizing the blockchain. This is especially important in a future<br>
scenario where the fee reward is larger than the block reward.<br>
<br>
BIP 115* by Luke-jr is even more specific. It enables users to create<br>
transactions which are only valid if they are mined on top of a<br>
specific block. While originally designed as a form of replay<br>
protection, it actually serves as a deterrent for miners to reorganize<br>
the blockchain. If they orphan a block, it will invalidate<br>
transactions that demanded the inclusion of the orphaned block. This<br>
increases the cost of intentionally reorganizing the blockchain.<br>
<br>
Coinjoin**, the act of combining payments of multiple users into a<br>
single transaction, can be seen as yet another method for users to be<br>
more specific. The fate of their payments are now intertwined with<br>
that of others. If miners wish to censor a single payment, they have<br>
to reject the entire transaction, and the associated fee amount.<br>
Techniques like mimblewimble simplify this process, by making coinjoin<br>
non-interactive.<br>
<br>
This brings us to a theoretical scenario where:<br>
<br>
- every block contains only a single coinjoin transaction<br>
- the validity of this transaction depends on the inclusion of a<br>
specific previous block<br>
- the block reward is negligible compared to transaction fees<br>
<br>
In this scenario, if miners wish to undo a specific transaction that<br>
happened two blocks ago, they would have to create three empty blocks<br>
(receiving negligible compensation) in order to overtake the longest<br>
chain. And even then, users can still refuse to let their new<br>
transactions be mined on top of the empty blocks, disincentivizing<br>
such behavior completely.<br>
<br>
While not easy to achieve in practice (e.g. resolving natural forks<br>
becomes more complicated), it demonstrates that users can become more<br>
empowered than they are today, benefitting censorship resistance***.<br>
It is this line of thinking that I wish to convey. Perhaps it may<br>
inspire further ideas in this direction.<br>
<br>
-- Ruben Somsen<br>
<br>
<br>
* BIP 115: <a href=3D"https://apc01.safelinks.protection.outlook.com/?url=
=3Dhttps%3A%2F%2Fgithub.com%2Fbitcoin%2Fbips%2Fblob%2Fmaster%2Fbip-0115.med=
iawiki&amp;amp;data=3D02%7C01%7C%7C48403f77efc14613e89b08d611f5980c%7C84df9=
e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636716143839246019&amp;amp;sdata=3Dre=
q4KYOcztXLAG%2Fu4RrmhLREGBF28JNTe45pO86kRd4%3D&amp;amp;reserved=3D0">
https://apc01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.=
com%2Fbitcoin%2Fbips%2Fblob%2Fmaster%2Fbip-0115.mediawiki&amp;amp;data=3D02=
%7C01%7C%7C48403f77efc14613e89b08d611f5980c%7C84df9e7fe9f640afb435aaaaaaaaa=
aaa%7C1%7C0%7C636716143839246019&amp;amp;sdata=3Dreq4KYOcztXLAG%2Fu4RrmhLRE=
GBF28JNTe45pO86kRd4%3D&amp;amp;reserved=3D0</a><br>
<br>
** Coinjoin: <a href=3D"https://apc01.safelinks.protection.outlook.com/?url=
=3Dhttps%3A%2F%2Fbitcointalk.org%2Findex.php%3Ftopic%3D279249.0&amp;amp;dat=
a=3D02%7C01%7C%7C48403f77efc14613e89b08d611f5980c%7C84df9e7fe9f640afb435aaa=
aaaaaaaaa%7C1%7C0%7C636716143839246019&amp;amp;sdata=3Dd%2B06jxrKubWhLwoInF=
Ego8eHvI9f1j74QN8WH7xrVos%3D&amp;amp;reserved=3D0">
https://apc01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fbitcoin=
talk.org%2Findex.php%3Ftopic%3D279249.0&amp;amp;data=3D02%7C01%7C%7C48403f7=
7efc14613e89b08d611f5980c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6367=
16143839246019&amp;amp;sdata=3Dd%2B06jxrKubWhLwoInFEgo8eHvI9f1j74QN8WH7xrVo=
s%3D&amp;amp;reserved=3D0</a><br>
<br>
*** Risk sharing principle:<br>
<a href=3D"https://apc01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2=
F%2Fgithub.com%2Flibbitcoin%2Flibbitcoin%2Fwiki%2FRisk-Sharing-Principle&am=
p;amp;data=3D02%7C01%7C%7C48403f77efc14613e89b08d611f5980c%7C84df9e7fe9f640=
afb435aaaaaaaaaaaa%7C1%7C0%7C636716143839246019&amp;amp;sdata=3DNA3HxqI5Pnu=
yaI9hyCaw0rcaFsrhD%2FXQB8biWJXej8g%3D&amp;amp;reserved=3D0">https://apc01.s=
afelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.com%2Flibbitcoi=
n%2Flibbitcoin%2Fwiki%2FRisk-Sharing-Principle&amp;amp;data=3D02%7C01%7C%7C=
48403f77efc14613e89b08d611f5980c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0=
%7C636716143839246019&amp;amp;sdata=3DNA3HxqI5PnuyaI9hyCaw0rcaFsrhD%2FXQB8b=
iWJXej8g%3D&amp;amp;reserved=3D0</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
bitcoin-dev@lists.linuxfoundation.org<br>
<a href=3D"https://apc01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2=
F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-dev&amp;amp;da=
ta=3D02%7C01%7C%7C48403f77efc14613e89b08d611f5980c%7C84df9e7fe9f640afb435aa=
aaaaaaaaaa%7C1%7C0%7C636716143839246019&amp;amp;sdata=3D9P7UetPmKWngjgjNPE0=
%2BAMgdzuL2DgqBLoLti82f23M%3D&amp;amp;reserved=3D0">https://apc01.safelinks=
.protection.outlook.com/?url=3Dhttps%3A%2F%2Flists.linuxfoundation.org%2Fma=
ilman%2Flistinfo%2Fbitcoin-dev&amp;amp;data=3D02%7C01%7C%7C48403f77efc14613=
e89b08d611f5980c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6367161438392=
46019&amp;amp;sdata=3D9P7UetPmKWngjgjNPE0%2BAMgdzuL2DgqBLoLti82f23M%3D&amp;=
amp;reserved=3D0</a><br>
</div>
</span></font></div>
</body>
</html>

--_000_PS2P216MB0179E804329D495A4EE6F4EC9D010PS2P216MB0179KORP_--