path: root/af/07a6c3f7de6dd5a4c89806acc3dea57153e748

Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id DCE6C1D81
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  6 Oct 2015 00:19:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com
	[209.85.213.169])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9F29A79
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  6 Oct 2015 00:19:26 +0000 (UTC)
Received: by igcpb10 with SMTP id pb10so75714239igc.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 05 Oct 2015 17:19:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=TWP3LAsMkx2mo0mcv0cOVbgPN7ecIG5VLAoxKwUSZlE=;
	b=FUqC06Vt6W/PkIUBX5EWTbq5+GOngsnEaKaijq+HYY1SUPRqtkTFkT2txIyr+f5pnZ
	HgunSHUqtHmZfPBzFXpvHJJhfXFTu6Ce7UgqPdfnAC1ZNlOCSsQQJGwKKK94ENAPaWrM
	KSE4Yo/akRrOlbxt14+jfLAPATskWumWoYQeKNkPmW3HTchQWGT8U7ks2C4y94Se2Acv
	HGMJBJzk/6CzRuvtr6nN+nanmYD885eOL4xHepvaQ+FR1/GI4eD0RKg2NOM0zB24Wk58
	VC4Zy376qjjixKnR/tTCc821ZvVyWg9PqlI10BjobKnaV2xIGs5TbjTSQ51Ppet7DLJQ
	bM+Q==
X-Gm-Message-State: ALoCoQmijq/ufgivKxpskP6OHVbTv57zZkKxWnhUU6D/6sMPilQSpVPtYS6Cd11XLlN/sBfS3Uqe
X-Received: by 10.50.30.39 with SMTP id p7mr12682133igh.40.1444090766085; Mon,
	05 Oct 2015 17:19:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.135.104 with HTTP; Mon, 5 Oct 2015 17:19:06 -0700 (PDT)
X-Originating-IP: [173.228.107.141]
In-Reply-To: <CAPWm=eUiXAagzasLmKQWRT5EKnMxfeiv6J7M9mm+MhDzG_VwQg@mail.gmail.com>
References: <20151003143056.GA27942@muck> <20151004083525.GA18291@navy>
	<561115C0.3080601@sky-ip.org>
	<CAPWm=eUiXAagzasLmKQWRT5EKnMxfeiv6J7M9mm+MhDzG_VwQg@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Mon, 5 Oct 2015 17:19:06 -0700
Message-ID: <CAOG=w-uEwwDGA3_RF1Epp=xLG7rS4y2O7f9EOfAUa1hAiWkLGQ@mail.gmail.com>
To: Alex Morcos <morcos@gmail.com>
Content-Type: multipart/alternative; boundary=047d7bdca5c02307360521649522
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW 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 <bitcoin-dev@lists.linuxfoundation.org>,
	Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to
 motivate the change
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: Tue, 06 Oct 2015 00:19:29 -0000

--047d7bdca5c02307360521649522
Content-Type: text/plain; charset=UTF-8

Alex, decreasing granularity is a soft-fork, increasing is a hard-fork.
Therefore I've kept the highest possible precision (1 second, 1 block) with
the expectation that at some point in the future if we need more low-order
bits we can soft-fork them to other purposes, we can decrease granularity
at that time.

On Mon, Oct 5, 2015 at 3:03 PM, Alex Morcos via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Peter,
>
> Your concern about whether this is the best way to use the nSequence
> field; would that be addressed by providing more high order bits to signal
> different uses of the field?  At a certain point we're really not limiting
> the future at all and there is something to be said for not letting the
> perfect be the enemy of the good.  I think it would be nice to make forward
> progress on BIPS 68,112, and 113 and move towards getting them finalized
> and implemented.  (Although I do suspect they aren't quite ready to go out
> with CLTV)
>
> What is the reasoning for having single second resolution on the time
> based sequence number locks?  Might it not make some sense to reduce that
> resolution and leave more low order bits as well?
>
> Alex
>
> On Sun, Oct 4, 2015 at 8:04 AM, s7r via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> Hi aj,
>>
>> On 10/4/2015 11:35 AM, Anthony Towns via bitcoin-dev wrote:
>> > On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via
>> > bitcoin-dev wrote:
>> >> So we need to make the case for two main things: 1) We have
>> >> applications that need a relative (instead of absolute CLTV) 2)
>> >> Additionally to RCLTV, we need to implement this via nSequence
>> >
>> >> However I don't think we've done a good job showing why we need
>> >> to implement this feature via nSequence. BIP68 describes the new
>> >> nSequence semantics, and gives the rational for them as being a
>> >> "Consensus-enforced tx replacement" mechanism, with a
>> >> bidirectional payment channel as an example of this in action.
>> >> However, the bidirectional payment channel concept itself can be
>> >> easily implemented with CLTV alone.
>> >
>> > Do you mean "with RCLTV alone" here?
>> >
>> > RCLTV/OP_CSV is used in lightning commitment transactions to
>> > enforce a delay between publishing the commitment transaction, and
>> > spending the output -- that delay is needed so that the
>> > counterparty has time to prove the commitment was revoked and claim
>> > the outputs as a penalty.
>> >
>>
>> I partially understand - can you please provide a simple Alice and Bob
>> example here with the exact scenario? Thanks. Why is there a need to
>> 'delay between publishing the commitment transaction and spending the
>> output'? If the absolute CLTV script reached its maturity it means
>> something went wrong (e.g. counterparty cheated or got hit by a bus)
>> so what is with the delay time needed for proving that the commitment
>> was revoked? I assume an absolute CLTV script reaching its maturity
>> (nLockTime) is the proof itself that the commitment was revoked - but
>> maybe I'm missing something obvious, sorry if this is the case.
>>
>> > Using absolute CLTV instead would mean that once the effective
>> > delay a commitment transaction has decreases over time -- initially
>> > it will be longer than desirable, causing unwanted delays in
>> > claiming funds when no cheating is going on; but over time it will
>> > become too short, which means there is not enough time to prove
>> > cheating (and the channel has to be closed prematurely). You can
>> > trade those things off and pick something that works, but it's
>> > always going to be bad.
>> >
>> I agree, I see the logic here. Absolute CLTV is not necessary inferior
>> to RCLTV - there are use cases and use cases. For example, you can
>> avoid unnecessary waiting until the nLockTime expires if you use
>> absolute CLTV in combination with P2SH (2/2). Again, it always depends
>> on the use case - it might be a good solution, it might not be such a
>> good solution, but even absolute CLTV alone clearly fixes a lot of
>> things and takes smart contracts to the next level.
>>
>> >> There is a small drawback in that the initial transaction could
>> >> be delayed, reducing the overall time the channel exists, but the
>> >> protocol already assumes that transactions can be reliably
>> >> confirmed within a day - significantly less than the proposed 30
>> >> days duration of the channel.
>> >
>> > Compared to using a CLTV with 30 days duration, With RCLTV a
>> > channel could be available for years (ie 20x longer), but in the
>> > case of problems funds could be reclaimed within hours or days (ie
>> > 30x faster).
>> >
>> Indeed. I for one _need_ CLTV / RCLTV in my day to day use cases, it
>> would be neat to have both, but if I can only have (for the time
>> being) absolute CLTV so be it - it's still a lot better.
>>
>> > But that's all about RCLTV vs CLTV, not about RCLTV vs
>> > nSequence/OP_CSV. ie, it needs BIP 112 (OP_CSV) but not necessarily
>> > BIP 68 (nSequence relative locktime), if they could be
>> > disentangled.
>> >
>> > You could do all that with "<n> OP_CHECK_HEIGHT_DELTA_VERIFY" that
>> > ignores nSequence, and directly compares the height of the current
>> > block versus the input tx's block (or the diff of their
>> > timestamps?) though, I think?
>> >
>> > I think the disadvantage is that (a) you have to look into the
>> > input transaction's block height when processing the script; and
>> > (b) you don't have an easy lookup to check whether the transaction
>> > can be included in the next block.
>> >
>> > You could maybe avoid (b) by using locktime though. Have "<n>
>> > OP_CHECK_RELATIVE_LOCKTIME_VERIFY" compare the transactions
>> > locktime against the input's block height or time; if the locktime
>> > is 0 or too low, the transaction is invalid. (So if nLockTime is in
>> > blockheight, you can only spend inputs with blockheight based
>> > OP_CRLTV tests; and if it's in blocktime, you can only spend inputs
>> > with blocktime based OP_CRLTV. "n" does need to encode whether it's
>> > time/block height though).
>> >
>> > That way, when you see a txn:
>> >
>> > - run the script. if you see <n> RCLTV, then + if the tx's locktime
>> > isn't set, it's invalid; drop it + if the input txn is unconfirmed,
>> > it's invalid; try again later + workout "locktime - n" if that's >=
>> > the input tx's block height/time, it's good; keep it in mempool,
>> > forward it, etc
>> >
>> > - if you're mining, include the tx when locktime hits, just like
>> > you would any other valid tx with a locktime
>> >
>> > I think the use cases for BIP68 (nSequence) are of the form:
>> >
>> > 1) published input; here's a signed tx that spends it to you,
>> > usable after a delay. might as well just use absolute locktime
>> > here, though.
>> >
>> > 2) here's an unpublished input, you can build your own transaction
>> > to spend it, just not immediately after it's published. BIP112 is
>> > required, and OP_RCLTV as defined above works fine, just include
>> > it in the published input's script.
>> >
>> > 3) here's an unpublished input, and a signed transaction spending
>> > it, that you can use to spend it after a delay. BIP68 is enough;
>> > but OP_RCLTV in the second transaction works here. however without
>> > normalised tx ids, the input could be malleated before
>> > publication, so maybe this use case isn't actually important
>> > anyway.
>> >
>> > So I think OP_CRLTV alone works fine for them too...
>> >
>> > (Does that make sense, or am I missing something obvious?)
>> >
>> > Cheers, aj
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.22 (MingW32)
>>
>> iQEcBAEBCAAGBQJWERXAAAoJEIN/pSyBJlsRypMH/2Q+jVRf4hWtPr9cs/06pXM9
>> mKHd2OPDEJO8HjSe+cIMCxOz76EZxXglUEkK4YV/huP0Tp0bcMp6EJxsZVD9L78k
>> dugyh2747ddL6aqRmt0ducTEfIC/Q4BxPA2HRQZkvyyIUQv2Tyo780bC0y8BwUpb
>> j/BQjFZwk4QgqkTlf5lbCgn85alOKHki2El04iALHc27pUiDWKQPPeNOy6po6mmD
>> /csvh4XOTQwCVy384ljuFBp0+QN7Z/zx4E8i6GqV2BmfNcveTG6Fc5KrHr2Ud4Th
>> RD8k6n9mLaPs6ufhVkgUiUqPzQsJ+ns+mm7OEUdd645Kxqxg3Tu1u32DgdpRcHk=
>> =U0N6
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--047d7bdca5c02307360521649522
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Alex, decreasing granularity is a soft-fork, increasing is=
 a hard-fork. Therefore I&#39;ve kept the highest possible precision (1 sec=
ond, 1 block) with the expectation that at some point in the future if we n=
eed more low-order bits we can soft-fork them to other purposes, we can dec=
rease granularity at that time.<br></div><div class=3D"gmail_extra"><br><di=
v class=3D"gmail_quote">On Mon, Oct 5, 2015 at 3:03 PM, Alex Morcos via bit=
coin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfou=
ndation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Peter,<d=
iv><br></div><div>Your concern about whether this is the best way to use th=
e nSequence field; would that be addressed by providing more high order bit=
s to signal different uses of the field?=C2=A0 At a certain point we&#39;re=
 really not limiting the future at all and there is something to be said fo=
r not letting the perfect be the enemy of the good.=C2=A0 I think it would =
be nice to make forward progress on BIPS 68,112, and 113 and move towards g=
etting them finalized and implemented. =C2=A0(Although I do suspect they ar=
en&#39;t quite ready to go out with CLTV)</div><div><br></div><div>What is =
the reasoning for having single second resolution on the time based sequenc=
e number locks?=C2=A0 Might it not make some sense to reduce that resolutio=
n and leave more low order bits as well?</div><div><br></div><div>Alex</div=
></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><=
br><div class=3D"gmail_quote">On Sun, Oct 4, 2015 at 8:04 AM, s7r via bitco=
in-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;<=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSA=
GE-----<br>
Hash: SHA256<br>
<br>
Hi aj,<br>
<span><br>
On 10/4/2015 11:35 AM, Anthony Towns via bitcoin-dev wrote:<br>
&gt; On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via<br>
&gt; bitcoin-dev wrote:<br>
&gt;&gt; So we need to make the case for two main things: 1) We have<br>
&gt;&gt; applications that need a relative (instead of absolute CLTV) 2)<br=
>
&gt;&gt; Additionally to RCLTV, we need to implement this via nSequence<br>
&gt;<br>
&gt;&gt; However I don&#39;t think we&#39;ve done a good job showing why we=
 need<br>
&gt;&gt; to implement this feature via nSequence. BIP68 describes the new<b=
r>
&gt;&gt; nSequence semantics, and gives the rational for them as being a<br=
>
&gt;&gt; &quot;Consensus-enforced tx replacement&quot; mechanism, with a<br=
>
&gt;&gt; bidirectional payment channel as an example of this in action.<br>
&gt;&gt; However, the bidirectional payment channel concept itself can be<b=
r>
&gt;&gt; easily implemented with CLTV alone.<br>
&gt;<br>
&gt; Do you mean &quot;with RCLTV alone&quot; here?<br>
&gt;<br>
&gt; RCLTV/OP_CSV is used in lightning commitment transactions to<br>
&gt; enforce a delay between publishing the commitment transaction, and<br>
&gt; spending the output -- that delay is needed so that the<br>
&gt; counterparty has time to prove the commitment was revoked and claim<br=
>
&gt; the outputs as a penalty.<br>
&gt;<br>
<br>
</span>I partially understand - can you please provide a simple Alice and B=
ob<br>
example here with the exact scenario? Thanks. Why is there a need to<br>
&#39;delay between publishing the commitment transaction and spending the<b=
r>
output&#39;? If the absolute CLTV script reached its maturity it means<br>
something went wrong (e.g. counterparty cheated or got hit by a bus)<br>
so what is with the delay time needed for proving that the commitment<br>
was revoked? I assume an absolute CLTV script reaching its maturity<br>
(nLockTime) is the proof itself that the commitment was revoked - but<br>
maybe I&#39;m missing something obvious, sorry if this is the case.<br>
<span><br>
&gt; Using absolute CLTV instead would mean that once the effective<br>
&gt; delay a commitment transaction has decreases over time -- initially<br=
>
&gt; it will be longer than desirable, causing unwanted delays in<br>
&gt; claiming funds when no cheating is going on; but over time it will<br>
&gt; become too short, which means there is not enough time to prove<br>
&gt; cheating (and the channel has to be closed prematurely). You can<br>
&gt; trade those things off and pick something that works, but it&#39;s<br>
&gt; always going to be bad.<br>
&gt;<br>
</span>I agree, I see the logic here. Absolute CLTV is not necessary inferi=
or<br>
to RCLTV - there are use cases and use cases. For example, you can<br>
avoid unnecessary waiting until the nLockTime expires if you use<br>
absolute CLTV in combination with P2SH (2/2). Again, it always depends<br>
on the use case - it might be a good solution, it might not be such a<br>
good solution, but even absolute CLTV alone clearly fixes a lot of<br>
things and takes smart contracts to the next level.<br>
<span><br>
&gt;&gt; There is a small drawback in that the initial transaction could<br=
>
&gt;&gt; be delayed, reducing the overall time the channel exists, but the<=
br>
&gt;&gt; protocol already assumes that transactions can be reliably<br>
&gt;&gt; confirmed within a day - significantly less than the proposed 30<b=
r>
&gt;&gt; days duration of the channel.<br>
&gt;<br>
&gt; Compared to using a CLTV with 30 days duration, With RCLTV a<br>
&gt; channel could be available for years (ie 20x longer), but in the<br>
&gt; case of problems funds could be reclaimed within hours or days (ie<br>
&gt; 30x faster).<br>
&gt;<br>
</span>Indeed. I for one _need_ CLTV / RCLTV in my day to day use cases, it=
<br>
would be neat to have both, but if I can only have (for the time<br>
being) absolute CLTV so be it - it&#39;s still a lot better.<br>
<div><div><br>
&gt; But that&#39;s all about RCLTV vs CLTV, not about RCLTV vs<br>
&gt; nSequence/OP_CSV. ie, it needs BIP 112 (OP_CSV) but not necessarily<br=
>
&gt; BIP 68 (nSequence relative locktime), if they could be<br>
&gt; disentangled.<br>
&gt;<br>
&gt; You could do all that with &quot;&lt;n&gt; OP_CHECK_HEIGHT_DELTA_VERIF=
Y&quot; that<br>
&gt; ignores nSequence, and directly compares the height of the current<br>
&gt; block versus the input tx&#39;s block (or the diff of their<br>
&gt; timestamps?) though, I think?<br>
&gt;<br>
&gt; I think the disadvantage is that (a) you have to look into the<br>
&gt; input transaction&#39;s block height when processing the script; and<b=
r>
&gt; (b) you don&#39;t have an easy lookup to check whether the transaction=
<br>
&gt; can be included in the next block.<br>
&gt;<br>
&gt; You could maybe avoid (b) by using locktime though. Have &quot;&lt;n&g=
t;<br>
&gt; OP_CHECK_RELATIVE_LOCKTIME_VERIFY&quot; compare the transactions<br>
&gt; locktime against the input&#39;s block height or time; if the locktime=
<br>
&gt; is 0 or too low, the transaction is invalid. (So if nLockTime is in<br=
>
&gt; blockheight, you can only spend inputs with blockheight based<br>
&gt; OP_CRLTV tests; and if it&#39;s in blocktime, you can only spend input=
s<br>
&gt; with blocktime based OP_CRLTV. &quot;n&quot; does need to encode wheth=
er it&#39;s<br>
&gt; time/block height though).<br>
&gt;<br>
&gt; That way, when you see a txn:<br>
&gt;<br>
&gt; - run the script. if you see &lt;n&gt; RCLTV, then + if the tx&#39;s l=
ocktime<br>
&gt; isn&#39;t set, it&#39;s invalid; drop it + if the input txn is unconfi=
rmed,<br>
&gt; it&#39;s invalid; try again later + workout &quot;locktime - n&quot; i=
f that&#39;s &gt;=3D<br>
&gt; the input tx&#39;s block height/time, it&#39;s good; keep it in mempoo=
l,<br>
&gt; forward it, etc<br>
&gt;<br>
&gt; - if you&#39;re mining, include the tx when locktime hits, just like<b=
r>
&gt; you would any other valid tx with a locktime<br>
&gt;<br>
&gt; I think the use cases for BIP68 (nSequence) are of the form:<br>
&gt;<br>
&gt; 1) published input; here&#39;s a signed tx that spends it to you,<br>
&gt; usable after a delay. might as well just use absolute locktime<br>
&gt; here, though.<br>
&gt;<br>
&gt; 2) here&#39;s an unpublished input, you can build your own transaction=
<br>
&gt; to spend it, just not immediately after it&#39;s published. BIP112 is<=
br>
&gt; required, and OP_RCLTV as defined above works fine, just include<br>
&gt; it in the published input&#39;s script.<br>
&gt;<br>
&gt; 3) here&#39;s an unpublished input, and a signed transaction spending<=
br>
&gt; it, that you can use to spend it after a delay. BIP68 is enough;<br>
&gt; but OP_RCLTV in the second transaction works here. however without<br>
&gt; normalised tx ids, the input could be malleated before<br>
&gt; publication, so maybe this use case isn&#39;t actually important<br>
&gt; anyway.<br>
&gt;<br>
&gt; So I think OP_CRLTV alone works fine for them too...<br>
&gt;<br>
&gt; (Does that make sense, or am I missing something obvious?)<br>
&gt;<br>
&gt; Cheers, aj<br>
</div></div>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2.0.22 (MingW32)<br>
<br>
iQEcBAEBCAAGBQJWERXAAAoJEIN/pSyBJlsRypMH/2Q+jVRf4hWtPr9cs/06pXM9<br>
mKHd2OPDEJO8HjSe+cIMCxOz76EZxXglUEkK4YV/huP0Tp0bcMp6EJxsZVD9L78k<br>
dugyh2747ddL6aqRmt0ducTEfIC/Q4BxPA2HRQZkvyyIUQv2Tyo780bC0y8BwUpb<br>
j/BQjFZwk4QgqkTlf5lbCgn85alOKHki2El04iALHc27pUiDWKQPPeNOy6po6mmD<br>
/csvh4XOTQwCVy384ljuFBp0+QN7Z/zx4E8i6GqV2BmfNcveTG6Fc5KrHr2Ud4Th<br>
RD8k6n9mLaPs6ufhVkgUiUqPzQsJ+ns+mm7OEUdd645Kxqxg3Tu1u32DgdpRcHk=3D<br>
=3DU0N6<br>
-----END PGP SIGNATURE-----<br>
<div><div>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>

--047d7bdca5c02307360521649522--