Delivery-date: Wed, 03 Apr 2024 13:08:53 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of bitcoin-dev@wuille.net designates 185.70.43.23 as permitted sender) client-ip=185.70.43.23;
Date: Wed, 03 Apr 2024 19:44:00 +0000
To: Tim Ruffing <crypto@timruffing.de>
From: Pieter Wuille <bitcoin-dev@wuille.net>
Cc: Matt Corallo <lf-lists@mattcorallo.com>, Brandon Black <freedom@reardencode.com>, Murch <murch@murch.one>, bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Time for an update to BIP2?
Message-ID: <4pVUOTuyyAbTJB_rTGNWS_TuR39NS5OoJvaSCyqjezAg265kPnCjXvqohFmWQ5ITb7XFZCJie-uV1AG3pVCI5H54dDuFP4OyomC9yiWDot0=@wuille.net>
In-Reply-To: <59fa94cea6f70e02b1ce0da07ae230670730171c.camel@timruffing.de>
References: <2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com> <e4048607-64b7-4772-b74e-4566a4b50bc0n@googlegroups.com> <9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org> <42e6c1d1d39d811e2fe7c4c5ce6e09c705bd3dbb.camel@timruffing.de> <d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com> <52a0d792-d99f-4360-ba34-0b12de183fef@murch.one> <f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com> <ZgWRu32FXzqqg69V@console> <9ebd08b0-7680-4896-aad3-1c225b764bcb@mattcorallo.com> <59fa94cea6f70e02b1ce0da07ae230670730171c.camel@timruffing.de>
Feedback-ID: 19463299:user:proton
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="b1_2sH74SEKCQpL8NcK5rhkFajFW7ZvZXlzjmVI60YTtE"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

This is a multi-part message in MIME format.

--b1_2sH74SEKCQpL8NcK5rhkFajFW7ZvZXlzjmVI60YTtE
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thank you for splitting off this discussion. I believe that lots of comment=
ators who see problems with the BIPs process fail to distinguish between th=
e editor being overloaded, and unclarity or disagreement about what the edi=
tor's job is supposed to be in the first place.

In particular, I've seen some comments akin to "assigning numbers shouldn't=
 take that much work", while the BIP2 sections you highlight do show that t=
he process does involve a lot more than that. Discussion about what the pro=
cess is supposed to be should be separate from a discussion about who will =
facilitate that process.

More comments inline below.

>

On Tuesday, April 2nd, 2024 at 9:17 AM, Tim Ruffing crypto@timruffing.de wr=
ote:

> BIP2, Section "BIP workflow" says this:
>
> "The BIP editors will not unreasonably reject a BIP. Reasons for
> rejecting BIPs include duplication of effort, disregard for formatting
> rules, being too unfocused or too broad, being technically unsound, not
> providing proper motivation or addressing backwards compatibility, or
> not in keeping with the Bitcoin philosophy. For a BIP to be accepted it
> must meet certain minimum criteria. It must be a clear and complete
> description of the proposed enhancement. The enhancement must represent
> a net improvement. The proposed implementation, if applicable, must be
> solid and must not complicate the protocol unduly."
>
> This is a lot of criteria for a simple editorial rule, hm? How could
> any editor judge if an enhancement represents a net improvement without
> opining on its merit? What's the Bitcoin philosophy?

Good point, this does seem to imply some value judgements. If we're open to=
 making changes to what the criteria for a BIP are supposed to be, I think =
it ought to include:

- Formatting: contains necessary sections/headers, license, ...
- Editorial qualities: proper English, organized, ...
- Discussion: must have been presented on the ML or other common fora, rece=
ived interest/discussion, ...
- Need for standardization: not every idea is worth publishing; if it isn't=
 likely to affect multiple projects/pieces of software, it can just be soft=
ware documentation instead.
- Scope: related to technology that supports the bitcoin currency.

This last one may be controversial, but I feel that some of the discussion =
the past months about the process has shown that there is unclarity/disagre=
ement here, and it would be good to have some guideline written out here. I=
 think scope will inevitably be somewhat of a grey zone, but I feel some li=
mits (whether spelled out or not) will exist regardless (nobody would consi=
der including the HTTP spec in scope for a BIP, I think?). One suggestion I=
 have seen (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-Oc=
tober/022072.html) is limiting to "extremely widespread standards used by t=
he entire Bitcoin community", but I feel that suffers from a "no true Scots=
man" fallacy (who gets to define what the "Bitcoin community" is, in a tech=
nology that to me seems designed for distrusting parties?), but would also =
under reasonable interpretations exclude several very useful BIPs today (so=
me wallet standards are useful for some software and not others) and likely=
 contribute to process friction (where do they move to?). I don't think tha=
t's a desirable situation.

I also don't think scope should be tied to specific technologies (e.g. it s=
houldn't just be about on-chain transactions, as e.g. that would exclude ad=
dress formats), but if not that, what scoping is useful? And to me, restric=
ting to technology that supports the bitcoin currency is fairly clear, reas=
onable, and avoids a circular definition. As an example, that would exclude=
 OpenTimestamps from scope (which was suggested in https://lists.linuxfound=
ation.org/pipermail/bitcoin-dev/2023-October/022077.html). I see that as an=
 unrelated application which happens to make use of the Bitcoin blockchain,=
 which on itself is one of the technologies that supports bitcoin - but is =
an indirection too far to be in scope.

Note that however none of the criteria I list above are quality assessments=
; I think it is essential that BIP editors can accept BIPs they themselves =
find abhorrent. People can strongly disagree about whether a proposed stand=
ard is a good idea, or even whether it falls within the "Bitcoin philosophy=
", without disagreeing whether it is at all related to bitcoin (the currenc=
y).

> By the way, Section "BIP Editor Responsibilities & Workflow" says this:
>
> "For each new BIP that comes in an editor does the following:
>
> - Read the BIP to check if it is ready: sound and complete. The ideas
> must make technical sense, even if they don't seem likely to be
> accepted.
> - [...]"
>
> Note how this is is (seemingly?) in conflict with the paragraph cited
> further above. What is "acceptance"? Acceptance by the editor, by the
> community (whoever that is), or by anyone else?

I don't see a problem here; my interpretation is that this is exactly about=
 excluding certain value judgements from what the editor is supposed to do:=
 they must judge soundness and completeness, without=E2=80=8B trying to gue=
ss whether the community is likely to accept the idea. "sound and complete"=
 is perhaps too vague as a criterion, but I'm in support of explicitly excl=
uding guessing of acceptance.

> BIP2 has other problems (a lot of which date back to BIP1):
>
> * It recommends licensing BIPs under BSD-2 or BSD-3, which are
> software licenses. It's not even clear if they're applicable to
>
> plain text. (The CC0 recommendation makes much more sense.)

No strong opinion about this, but that sounds reasonable.

> * The Comments-URI thing is outdated and everyone seems to ignore it.
>
> Comments-Summary is even weirder.

Agreed. It's unused, and sometimes misinterpreted. I think we should get ri=
d of it.

> * "Informational BIPs do not necessarily represent a Bitcoin community
> consensus or recommendation". Aha, does this imply that Standards
> Track BIPs need to represent a Bitcoin community consensus or
>
> recommendation?

Indeed. I don't think BIPs should be representing community consensus or re=
commendations. But perhaps they can document individual pieces of evidence =
of acceptance; see further?

> * Ever tried to write pseudocode or LaTeX in mediawiki format? It's
>
> more than annoying, believe me.

I'd like permitting BIPs to be written in markdown.

> Moreover, the entire "BIP status field" section is an attempt at
> formalizing and describing the process of changing Bitcoin. That leads
> to statements like these that specify when a BIP should be "Final"
>
> * "A soft-fork BIP strictly requires a clear miner majority expressed
> by blockchain voting (eg, using BIP 9)." That statement is highly
> controversial. The point is that it simply doesn't belong in BIP2.
> * "API/RPC and application layer BIPs must be implemented by at least
> two independent and compatible software applications." same here
> * Peer services BIPs should be observed to be adopted by at least 1%
>
> of public listening nodes for one month.

Some forms of Status are useful I think, but they ought to reflect the auth=
or's intent, not the community's perception. E.g. "Draft", "Proposed", and =
"Withdrawn" make sense to me for any kind of standard. In Draft stage more =
substantial changes could be permitted, but would convey the idea isn't yet=
 intended for adoption. Of course, the BIP1 status fields weren't really us=
ed, and the BIP2 status fields don't seem to be doing much better. If we as=
sume that BIP3 status fields aren't going to be used either this is all for=
 nought, but perhaps it's still worth trying with a significantly simplifie=
d assortment of statuses.

Things like "Active / Final" and "Rejected" relate to community acceptance,=
 and I agree those don't belong in BIPs. Instead, could we perhaps have a f=
ield that indicates objective evidence of acceptance, such as listing which=
 software projects have implemented/adopted it?

As far as judging consensus goes, perhaps actual consensus changes are an e=
xception? I feel that for those, an "Accepted" status may actually make sen=
se, because they actually require the ecosystem to have agreement about. Bu=
t even then, it could be restricted to be an after-the-fact piece of eviden=
ce (whatever its activation rules are, they are met), rather than a judgeme=
nt of community perception.

Regarding the "at least two independent and compatible software application=
s", I don't think this is a bad principle: good standards should be impleme=
ntable by many, and having multiple implementations is an objective way of =
assessing that. I'm not sure that means being a requirement for its status,=
 but at least an intent to have multiple implementations is a useful condit=
ion for the "Need for standardization" rule I suggest above.

> The problems are similar to the Comments-Summary field whose purpose is
> to represent a community judgment of the BIP. It can have these values:
> * No comments yet.
> * Unanimously Recommended for implementation
> * Unanimously Discourage for implementation
> * Mostly Recommended for implementation, with some Discouragement
> * Mostly Discouraged for implementation, with some Recommendation
>
> There's a reason why noone really uses this. Like the Status field, it
> requires that someone (the editor? BIP2 doesn't specify this) makes a
> judgement that looks somewhat authoritative, because it will end up in
>
> the BIP header/metadata.

Agreed.

> I think we should simply drop anything that requires an examination of
> the meat of the BIP, e.g., the Status and Comments-* fields, and the
> requirement to check the meat of a BIP. Instead, we should work on a
> new process BIP that merely describes a simple process of publishing
> BIPs, in which the editors focus on purely formal and editorial issues
> (e.g., formatting, license, readability, filtering spam, ...). It's
> great when they guide BIP authors by providing feedback on the
> presentation of an idea, or even on the idea itself, but they shouldn't
> be required to make decisions based on the technical or philosophical
>
> merit of a BIP

I think my view is somewhat more restrictive than yours, e.g. that BIPs oug=
ht to satisfy some scope and need for standardization criteria, but I agree=
 that as written in BIP2 today, Editors have too many judgement calls to ma=
ke.

--
Pieter

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
bitcoindev/4pVUOTuyyAbTJB_rTGNWS_TuR39NS5OoJvaSCyqjezAg265kPnCjXvqohFmWQ5IT=
b7XFZCJie-uV1AG3pVCI5H54dDuFP4OyomC9yiWDot0%3D%40wuille.net.

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

<div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><p></p><div=
 style=3D"font-family: Arial, sans-serif; font-size: 14px;"><p>Thank you fo=
r splitting off this discussion. I believe that lots of=20
commentators who see problems with the BIPs process fail to distinguish=20
between the editor being overloaded, and unclarity or disagreement about
 what the editor's job is supposed to be in the first place.<br><br>
In particular, I've seen some comments akin to "assigning numbers=20
shouldn't take that much work", while the BIP2 sections you highlight do
 show that the process does involve a lot more than that. Discussion about=
=20
what the process is supposed to be should be separate from a discussion=20
about who will facilitate that process.<br><br>
More comments inline below.</p><blockquote><p></p></blockquote><br></div>
<div class=3D"protonmail_signature_block protonmail_signature_block-empty" =
style=3D"font-family: Arial, sans-serif; font-size: 14px;">
    <div class=3D"protonmail_signature_block-user protonmail_signature_bloc=
k-empty">
       =20
            </div>
   =20
            <div class=3D"protonmail_signature_block-proton protonmail_sign=
ature_block-empty">On Tuesday, April 2nd, 2024 at 9:17 AM, Tim Ruffing <a h=
ref=3D"mailto:crypto@timruffing.de">crypto@timruffing.de</a> wrote:</div></=
div><p></p>
<p></p><blockquote><p>
BIP2, Section "BIP workflow" says this:</p>
<p>"The BIP editors will not unreasonably reject a BIP. Reasons for<br>
rejecting BIPs include duplication of effort, disregard for formatting<br>
rules, being too unfocused or too broad, being technically unsound, not<br>
providing proper motivation or addressing backwards compatibility, or<br>
not in keeping with the Bitcoin philosophy. For a BIP to be accepted it<br>
must meet certain minimum criteria. It must be a clear and complete<br>
description of the proposed enhancement. The enhancement must represent<br>
a net improvement. The proposed implementation, if applicable, must be<br>
solid and must not complicate the protocol unduly."</p>
<p>This is a lot of criteria for a simple editorial rule, hm? How could<br>
any editor judge if an enhancement represents a net improvement without<br>
opining on its merit? What's the Bitcoin philosophy?</p>
</blockquote><p>Good point, this does seem to imply some value judgements. =
If we're open to making changes to what the criteria for a BIP are supposed=
 to be, I think it ought to include:</p><p></p><ul data-editing-info=3D"{&q=
uot;orderedStyleType&quot;:1,&quot;unorderedStyleType&quot;:1}"><li style=
=3D"list-style-type: disc;"><span>Formatting: contains necessary sections/h=
eaders, license, ...</span></li><li style=3D"list-style-type: disc;"><span>=
Editorial qualities: proper English, organized, ...<br></span></li><li styl=
e=3D"list-style-type: disc;"><span>Discussion: must have been presented on =
the ML or other common fora, received interest/discussion, ...</span></li><=
li style=3D"list-style-type: disc;"><span>Need for standardization: not eve=
ry idea is worth publishing; if it isn't likely to affect multiple projects=
/pieces of software, it can just be software documentation instead.</span><=
/li><li style=3D"list-style-type: disc;"><span>Scope: related to technology=
 that supports the bitcoin currency.</span></li></ul><div><br></div><div>Th=
is last one may be controversial, but I feel that some of the discussion th=
e past months about the process has shown that there is unclarity/disagreem=
ent here, and it would be good to have some guideline written out here. I t=
hink scope will inevitably be somewhat of a grey zone, but I feel some limi=
ts (whether spelled out or not) will exist regardless (nobody would conside=
r including the HTTP spec in scope for a BIP, I think?). One suggestion I h=
ave seen (<span><a target=3D"_blank" rel=3D"noreferrer nofollow noopener" h=
ref=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October=
/022072.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-=
October/022072.html</a>) is limiting to "extremely widespread standards use=
d by the entire Bitcoin community", but I feel that suffers from a "no true=
 Scotsman" </span>fallacy (who gets to define what the "Bitcoin community" =
is, in a technology that to me seems designed for distrusting parties?), bu=
t would also under reasonable interpretations exclude several very useful B=
IPs today (some wallet standards are useful for some software and not other=
s) and likely contribute to process friction (where do they move to?). I do=
n't think that's a desirable situation.<br></div><div><br></div><div>I also=
 don't think scope should be tied to specific technologies (e.g. it shouldn=
't just be about on-chain transactions, as e.g. that would exclude address =
formats), but if not that, what scoping is useful? And to me, restricting t=
o technology that supports the bitcoin currency is fairly clear, reasonable=
, and avoids a circular definition. As an example, that would exclude OpenT=
imestamps from scope (which was suggested in <span><a target=3D"_blank" rel=
=3D"noreferrer nofollow noopener" href=3D"https://lists.linuxfoundation.org=
/pipermail/bitcoin-dev/2023-October/022077.html">https://lists.linuxfoundat=
ion.org/pipermail/bitcoin-dev/2023-October/022077.html</a>). I see that as =
an unrelated application which happens to make use of the Bitcoin blockchai=
n, which on itself is one of the technologies that supports bitcoin - but i=
s an indirection too far to be in scope.<br></span></div><div><span><br></s=
pan></div><div><span>Note that however none of the criteria I list above ar=
e quality assessments; I think it is essential that BIP editors can accept =
BIPs they themselves find abhorrent. People can strongly disagree about whe=
ther a proposed standard is a good idea, or even whether it falls within th=
e "Bitcoin philosophy", without disagreeing whether it is at all related to=
 bitcoin (the currency).<br></span></div><p><br></p><blockquote><p>By the w=
ay, Section "BIP Editor Responsibilities &amp; Workflow" says this:</p>
<p>"For each new BIP that comes in an editor does the following:</p>
<p>- Read the BIP to check if it is ready: sound and complete. The ideas<br=
>
must make technical sense, even if they don't seem likely to be<br>
accepted.<br>
- [...]"</p>
<p>Note how this is is (seemingly?) in conflict with the paragraph cited<br=
>
further above. What is "acceptance"? Acceptance by the editor, by the<br>
community (whoever that is), or by anyone else?</p>
</blockquote><p>I don't see a problem here; my interpretation is that this =
is exactly about excluding certain value judgements from what the editor is=
 supposed to do: they must judge soundness and completeness, <b>without</b>=
=E2=80=8B trying to guess whether the community is likely to accept the ide=
a. "sound and complete" is perhaps too vague as a criterion, but I'm in sup=
port of explicitly excluding guessing of acceptance.<br></p><p><br></p><blo=
ckquote><p>BIP2 has other problems (a lot of which date back to BIP1):<br><=
/p><p>
* It recommends licensing BIPs under BSD-2 or BSD-3, which are<br>
software licenses. It's not even clear if they're applicable to<br></p><p>
plain text. (The CC0 recommendation makes much more sense.)</p></blockquote=
><p>No strong opinion about this, but that sounds reasonable.</p><p><br></p=
><blockquote><p>
* The Comments-URI thing is outdated and everyone seems to ignore it.<br></=
p><p>
Comments-Summary is even weirder.</p></blockquote><p>Agreed. It's unused, a=
nd sometimes misinterpreted. I think we should get rid of it.</p><p><br></p=
><blockquote><p>
* "Informational BIPs do not necessarily represent a Bitcoin community<br>
consensus or recommendation". Aha, does this imply that Standards<br>
Track BIPs need to represent a Bitcoin community consensus or<br></p><p>
recommendation?</p></blockquote><p>Indeed. I don't think BIPs should be rep=
resenting community consensus or recommendations. But perhaps they can docu=
ment individual pieces of evidence of acceptance; see further?</p><p><br></=
p><blockquote><p>
* Ever tried to write pseudocode or LaTeX in mediawiki format? It's<br></p>=
<p>
more than annoying, believe me.</p></blockquote><p>I'd like permitting BIPs=
 to be written in markdown.</p><p><br></p><blockquote>
<p>Moreover, the entire "BIP status field" section is an attempt at<br>
formalizing and describing the process of changing Bitcoin. That leads<br>
to statements like these that specify when a BIP should be "Final"</p>
<p>* "A soft-fork BIP strictly requires a clear miner majority expressed<br=
>
by blockchain voting (eg, using BIP 9)." That statement is highly<br>
controversial. The point is that it simply doesn't belong in BIP2.<br>
* "API/RPC and application layer BIPs must be implemented by at least<br>
two independent and compatible software applications." same here<br>
* Peer services BIPs should be observed to be adopted by at least 1%<br></p=
><p>
of public listening nodes for one month.</p></blockquote><p><br></p><p>Some=
 forms of Status are useful I think, but they ought to reflect the author's=
 intent, not the community's perception. E.g. "Draft", "Proposed", and "Wit=
hdrawn" make sense to me for any kind of standard. In Draft stage more subs=
tantial changes could be permitted, but would convey the idea isn't yet int=
ended for adoption. Of course, the BIP1 status fields weren't really used, =
and the BIP2 status fields don't seem to be doing much better. If we assume=
 that BIP3 status fields aren't going to be used either this is all for nou=
ght, but perhaps it's still worth trying with a significantly simplified as=
sortment of statuses.<br></p><p>Things like "Active / Final" and "Rejected"=
 relate to community acceptance, and I agree those don't belong in BIPs. In=
stead, could we perhaps have a field that indicates objective evidence of a=
cceptance, such as listing which software projects have implemented/adopted=
 it?</p><p>As far as judging consensus goes, perhaps actual consensus chang=
es are an exception? I feel that for those, an "Accepted" status may actual=
ly make sense, because they actually require the ecosystem to have agreemen=
t about. But even then, it could be restricted to be an after-the-fact piec=
e of evidence (whatever its activation rules are, they are met), rather tha=
n a judgement of community perception.<br></p><p>Regarding the "at least tw=
o independent and compatible software applications", I don't think this is =
a bad principle: good standards should be implementable by many, and having=
 multiple implementations is an objective way of assessing that. I'm not su=
re that means being a requirement for its status, but at least an intent to=
 have multiple implementations is a useful condition for the "Need for stan=
dardization" rule I suggest above.</p><p><br></p><blockquote>
<p>The problems are similar to the Comments-Summary field whose purpose is<=
br>
to represent a community judgment of the BIP. It can have these values:<br>
* No comments yet.<br>
* Unanimously Recommended for implementation<br>
* Unanimously Discourage for implementation<br>
* Mostly Recommended for implementation, with some Discouragement<br>
* Mostly Discouraged for implementation, with some Recommendation</p>
<p>There's a reason why noone really uses this. Like the Status field, it<b=
r>
requires that someone (the editor? BIP2 doesn't specify this) makes a<br>
judgement that looks somewhat authoritative, because it will end up in<br><=
/p><p>
the BIP header/metadata.</p></blockquote><p>Agreed.</p><p><br></p><blockquo=
te>
<p>I think we should simply drop anything that requires an examination of<b=
r>
the meat of the BIP, e.g., the Status and Comments-* fields, and the<br>
requirement to check the meat of a BIP. Instead, we should work on a<br>
new process BIP that merely describes a simple process of publishing<br>
BIPs, in which the editors focus on purely formal and editorial issues<br>
(e.g., formatting, license, readability, filtering spam, ...). It's<br>
great when they guide BIP authors by providing feedback on the<br>
presentation of an idea, or even on the idea itself, but they shouldn't<br>
be required to make decisions based on the technical or philosophical<br></=
p><p>
merit of a BIP</p></blockquote><p>I think my view is somewhat more restrict=
ive than yours, e.g. that BIPs ought to satisfy some scope and need for sta=
ndardization criteria, but I agree that as written in BIP2 today, Editors h=
ave too many judgement calls to make.</p><p></p><div>--</div><div>Pieter</d=
iv><div><br></div><p></p><p><br></p><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/4pVUOTuyyAbTJB_rTGNWS_TuR39NS5OoJvaSCyqjezAg265kPnCjX=
vqohFmWQ5ITb7XFZCJie-uV1AG3pVCI5H54dDuFP4OyomC9yiWDot0%3D%40wuille.net?utm_=
medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitco=
indev/4pVUOTuyyAbTJB_rTGNWS_TuR39NS5OoJvaSCyqjezAg265kPnCjXvqohFmWQ5ITb7XFZ=
CJie-uV1AG3pVCI5H54dDuFP4OyomC9yiWDot0%3D%40wuille.net</a>.<br />

--b1_2sH74SEKCQpL8NcK5rhkFajFW7ZvZXlzjmVI60YTtE--