From ed194a1f0da2d6ceabec11af7f745e31824f66b4 Mon Sep 17 00:00:00 2001 From: ryanthegentry Date: Wed, 27 Oct 2021 10:25:20 -0500 Subject: [PATCH] Update README and add bLIP-0001 --- README.md | 20 ++- blip-0001.md | 306 ++++++++++++++++++++++++++++++++++++++ blip-0001/blip-0001-1.png | Bin 0 -> 10389 bytes 3 files changed, 325 insertions(+), 1 deletion(-) create mode 100644 blip-0001.md create mode 100644 blip-0001/blip-0001-1.png diff --git a/README.md b/README.md index 10325d0..6e64b8a 100644 --- a/README.md +++ b/README.md @@ -1 +1,19 @@ -# blips +bLIP stands for Bitcoin Lightning Improvement Proposal. A bLIP is a design document +providing information to the Lightning community, or describing a new feature for +the Lightning Network. The bLIP should provide a concise technical specification of +the feature and a rationale for the feature. The bLIP author is responsible for +building consensus within the community and documenting dissenting opinions. +Importantly, if a feature is intended to become universal or near universal, it must +be a [BOLT](https://github.com/lightning/bolts). + +People wishing to submit bLIPs (Bitcoin Lightning Improvement Proposals) should +first propose their idea to the [Lightning development mailing +list](https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev). After +discussion, please open a PR. After copy-editing and acceptance, it will be +published here. + +For more detail on the process, please read bLIP-0001. + +| Number | Title | Author | Status | +|--------|-------|--------|--------| +|1|bLIP Process|Ryan Gentry|Active| diff --git a/blip-0001.md b/blip-0001.md new file mode 100644 index 0000000..2703c87 --- /dev/null +++ b/blip-0001.md @@ -0,0 +1,306 @@ +``` +bLIP: 1 +Title: bLIP process +Status: Active +Author: Ryan Gentry +Created: 2021-05-21 +Post-History: 2021-06-30: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003086.html + [lightning-dev] bLIPs: A proposal for community-driven app layer and protocol extension standardization +License: CC0 +``` + +# Abstract + +bLIP stands for Bitcoin Lightning Improvement Proposal. A bLIP is a design document +providing information to the Lightning community, or describing a new feature for +the Lightning Network. The bLIP should provide a concise technical specification of +the feature and a rationale for the feature. The bLIP author is responsible for +building consensus within the community and documenting dissenting opinions. +Importantly, if a feature is intended to become universal or near universal, it must +be a BOLT. + +# Copyright + +This bLIP is licensed under the CC0 license. + +# Rationale + +As the Lightning community has grown, new features, standards, and protocols have +been developed outside of the BOLT specification process: particularly at the +application level that isn’t described within the core BOLT documents. This is great! +But in the spirit of interoperability, documenting features, standards, and protocols +in a single location with a standard format will make it easy on future adopters. + +In particular, there are (at least) three scarce sets of identifiers used in Lightning +Network protocol development that benefit from central organization and documentation +to avoid potential clashes: + +* **Feature Bits** are used to designate that a given node supports a given feature, and +are publicly broadcasted on the Lightning Network. bLIPs may introduce new Feature Bit +assignments > `100`, as those are set aside for experimental features, with the caveat +that Feature Bit assignments > `1000` are discouraged from mainnet usage. Feature Bits are +assigned and specified in [Bolt + #9](https://github.com/lightningnetwork/lightning-rfc/blob/master/09-features.md). +* **Message Types** are used to indicate how to interpret the `payload` feature of a +Lightning message. Types `32768`-`65535` are set aside for experimental and +application-specific messages, which are best suited to be documented in a bLIP. +Message Types are assigned and specified in [Bolt + #1](https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md). +* **Type-Length-Values (TLVs)** are used to allow for the backwards-compatible addition +of new fields to existing message types (as described in in [Bolt + #1](https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md)). +bLIPs may introduce new TLV fields to existing messages, using `type`s greater than `65536`. + +Potentially more scarce sets of identifiers exist (e.g. [BOLT + #4](https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md#failure-messages) +onion failure messages, [BOLT + #7](https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#the-channel_update-message) `channel_update` `channel_flags` and `message_flags`, and [BOLT + #11](https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md#tagged-fields) +invoice tagged fields) in the Lightning Network protocol. If/when bLIPs are made that +require these identifiers, further specification of how and where to assign and allocate +them can be accomplished. + +bLIPs will serve as the primary mechanism for proposing new features for the Lightning +Network protocol, documenting their design, and avoiding collisions of these scarce +identifiers (as some proposals may request one or more). Hopefully, they will provide +an avenue for developers to quickly get feedback on their ideas outside of the main BOLT +process. Because the bLIPs are maintained as text files in a versioned repository, +their revision history is the historical record of the feature proposal. + +It is highly recommended that a single bLIP contain a single key proposal or new idea. +More focused bLIPs will tend to be more successful. If in doubt, a bLIP should be +split into several well-focused ones. + +For Lightning developers, bLIPs are a convenient way to track the progress of their +implementation. Ideally, each implementation editor would list the bLIPs they have +implemented. This will give end users a convenient way to know the current status of +a given implementation or library. + +# bLIP Workflow + +The bLIP process begins with a new idea for Lightning. Each potential bLIP must have +a champion -- someone who writes the bLIP using the style and format described below, +shepherds the discussions in the appropriate forums, and attempts to build community +consensus around the idea. The bLIP champion (a.k.a. Author) should first attempt to +ascertain whether the idea is bLIP-able. The first step should be to search past +discussions to see if an idea has been considered before, and if so, what issues arose +in its progression. Such discussion generally happens on the [Lightning development +mailing list](https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev), or +in the #lightning-dev IRC channel. Additionally, the champion should check the [Bitcoin +Improvement Proposal (BIP) repository](https://github.com/bitcoin/bips) and the +[Discrete Log Contract (DLC) specification](https://github.com/discreetlogcontracts/dlcspecs) +to avoid duplication of proposals. + +Once the champion has asked the Lightning community as to whether an idea has any +chance of acceptance, a draft bLIP should be presented to the [Lightning development +mailing list](https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev). This +gives the author a chance to flesh out the draft bLIP to make it properly formatted, +of high quality, and to address additional concerns about the proposal. Following a +discussion, the proposal should be submitted to the [bLIPs repository of the lightning +organization](https://github.com/lightning/blips) as a pull request. This +draft must be written in bLIP style as described below, and its bLIP number will be +the PR number automatically assigned by Github (or, if preferred by the author, the +Issue # if there was discussion in the Issues section of this repository about this bLIP). + +When the bLIP draft is complete, the editors will check the requested Feature Bit, Message +Type, and/or TLV assignments for collisions. If there are no issues, the bLIPs editors will +merge the pull request into the [bLIPs repository](https://github.com/lightning/blips). +The editors will not unreasonably reject a bLIP. Reasons for rejecting bLIPs 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 and Lightning Network +philosophy. For a bLIP 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. + +The bLIP author may update the draft as necessary in the git repository. Updates to +drafts should also be submitted by the author as pull requests. + +## Transferring bLIP Ownership + +It occasionally becomes necessary to transfer ownership of bLIPs to a new champion. In +general, we'd like to retain the original author as a co-author of the transferred bLIP, +but that's really up to the original author. A good reason to transfer ownership is +because the original author no longer has the time or interest in updating it or +following through with the bLIP process, or has fallen off the face of the 'net (i.e. is +unreachable or not responding to email). A bad reason to transfer ownership is because +you don't agree with the direction of the bLIP. We try to build consensus around a bLIP, +but if that's not possible, you can always submit a competing bLIP. + +If you are interested in assuming ownership of a bLIP, send a message asking to take over, +addressed to both the original author and the bLIP editor. If the original author doesn't +respond to email in a timely manner, the bLIP editor will make a unilateral decision (it's +not like such decisions can't be reversed). + +### bLIP Editors + +The current bLIP editors are: + +* Bastien Teinturier (@t-bast) +* Christian Decker (@cdecker) +* Lisa Neigut (@niftynei) +* Matt Corallo (@TheBlueMatt) +* Olaoluwa Osuntokun (@roasbeef) +* Ryan Gentry (@ryanthegentry) +* Rusty Russell (@rustyrussell) + +### bLIP Editor Responsibilities & Workflow + +For each new bLIP submission, the editors do the following: + +* Read the bLIP to check if it is ready: sound and complete. The ideas must make technical +sense, even if they don't seem likely to get to final status. +* The title should accurately describe the content. +* The bLIP draft must have been sent to the lightning-dev mailing list for discussion. +* Motivation and backward compatibility (when applicable) must be addressed. +* Licensing terms must be acceptable for bLIPs. + +If the bLIP isn't ready, the editor will send it back to the author for revision, with +specific instructions. + +Once the bLIP is ready for the repository, the bLIP editor will: + +* Assign a bLIP number (generally the PR number or, if preferred by the author, the Issue # +if there was discussion in the Issues section of this repository about this bLIP) +* Check the requested Feature Bit, Message Type, and/or TLV assignments for collisions. +* Merge the corresponding pull request +* Send a message back to the bLIP author with the next steps. + +The bLIP editors are intended to fulfill administrative and editorial responsibilities. +They do not pass judgement on bLIPs. The bLIP editors monitor bLIP changes, and update bLIP +headers as appropriate. + +## What belongs in a successful bLIP? + +bLIPs should be written in Markdown format. + +Each bLIP should have the following parts: + +* **Preamble** -- Headers containing metadata about the bLIP (see below). +* **Abstract** -- A short (~200 word) description of the technical issue being addressed. +* **Copyright** -- The bLIP must be explicitly licensed under acceptable copyright terms (see below). +* **Motivation** -- The motivation is critical for bLIPs that want to change the Lightning +protocol. It should clearly explain why the existing protocol is inadequate to address +the problem that the bLIP solves. +* **Rationale** -- The rationale fleshes out the specification by describing what motivated +the design and why particular design decisions were made. It should describe alternate +designs that were considered and related work. The rationale should provide evidence of +consensus within the community and discuss important objections or concerns raised +during discussion. +* **Specification** -- The technical specification should describe the syntax and semantics +of any new feature. The specification should be detailed enough to allow competing, +interoperable implementations for any of the current Lightning implementations. +* **Universality** -- This section should discuss why the given feature is not intended to be +universal and why it's still a good idea as a non-universal protocol. New features intended to be +universally deployed should go through the BOLTs process instead. +* **Backwards Compatibility** -- All bLIPs that introduce backwards incompatibilities must +include a section describing these incompatibilities and their severity. The bLIP must +explain how the author proposes to deal with these incompatibilities. +* **Reference Implementation** -- The reference implementation must be completed before any +bLIP is given status "Final", but it need not be completed before the bLIP is accepted. It +is better to finish the specification and rationale first and reach consensus on it before +writing code. The final implementation must include test code and documentation appropriate +for the Lightning protocol. + +### bLIP Header Preamble + +Each bLIP must begin with an RFC 822 style header preamble. The headers must appear in the +following order. Headers marked with "*" are optional and are described below. All other +headers are required. + +``` +bLIP: bLIP number, this is determined by the PR or Issue number +Title: bLIP title +Author: list of the author's or authors' name(s) and/or username(s), or name(s) and +email(s). Details are below. +* Discussions-To: a url pointing to the official discussions thread +Status: Draft, Active, Proposed, Deferred, Rejected, Withdrawn, Final, Replaced, Obsolete +Created: date created on, in ISO 8601 (yyyy-mm-dd) format +* Post-History: dates of postings to lightning-dev mailing list, or link to thread in + mailing list archive +License: abbreviation for approved license(s) +* License-Code: abbreviation for code under different approved license(s) +* Requires: bLIP number(s) +* Replaces: bLIP number +* Superseded-By: bLIP number +``` + +The Author header lists the names and email addresses of all the authors/owners of the bLIP. +The format of the Author header value must be: + +`Random J. User ` + +If there are multiple authors, each should be on a separate line following RFC 2822 +continuation line conventions. + +While a bLIP is in private discussions (usually during the initial Draft phase), a +Discussions-To header will indicate the mailing list or URL where the bLIP is being discussed. +No Discussions-To header is necessary if the bLIP is being discussed privately with the author, +or on the bitcoin email mailing lists. + +The Created header records the date that the bLIP was assigned a number, while Post-History +is used to record when new versions of the bLIP are posted to bitcoin mailing lists. Dates +should be in yyyy-mm-dd format, e.g. 2001-08-14. Post-History is permitted to be a link to a +specific thread in a mailing list archive. + +bLIPs may have a Requires header, indicating the bLIP numbers that this bLIP depends on. + +bLIPs may also have a Superseded-By header indicating that a bLIP has been rendered +obsolete by a later document; the value is the number of the bLIP that replaces the +current document. The newer bLIP must have a Replaces header containing the number of the +bLIP that it rendered obsolete. + +### bLIP status field + +The typical paths of the status of bLIPs are as follows: + +![](blip-0001/blip-0001-1.png) + +* **Draft** - The first formally tracked stage of a bLIP in development. A bLIP is merged by +a bLIP Editor into the proposals folder of the lightning-rfc repository when properly formatted. +* **Deferred** - The bLIP editor may also change the status to Deferred when no progress is being +made on the bLIP. +* **Withdrawn** - Champions of a bLIP may decide on their own to change the status between Draft, +Deferred, or Withdrawn. +* **Rejected** - bLIPs should be changed from Draft status to Rejected status, upon request by any +person, if they have not made progress in three years. Such a bLIP may be changed to Draft +status if the champion provides revisions that meaningfully address public criticism of the +proposal, or to Proposed status if it meets the criteria required as described in the previous +paragraph. +* **Proposed** - a bLIP may only change status from Draft (or Rejected) to Proposed, when the author +deems it is complete, has a working implementation (where applicable), and has community plans +to progress it to the Final status. +* **Final / Active** - a Proposed bLIP may progress to Final only when specific criteria reflecting +real-world adoption has occurred. This is different for each bLIP depending on the nature of +its proposed changes, which will be expanded on below. Evaluation of this status change should +be objectively verifiable, and/or be discussed on the development mailing list. A bLIP may change +status from Draft to Active when it achieves rough consensus on the mailing list. Such a proposal +is said to have rough consensus if it has been open to discussion on the development mailing list +for at least one month, and no person maintains any unaddressed substantiated objections to it. +Addressed or obstructive objections may be ignored/overruled by general agreement that they have +been sufficiently addressed, but clear reasoning must be given in such circumstances. +* **Replaced or Obsolete** - when a Final bLIP is no longer relevant, its status may be changed to +Replaced or Obsolete (which is equivalent to Replaced). This change must also be objectively +verifiable and/or discussed. + +### Auxiliary Files + +bLIPs may include auxiliary files such as diagrams. Auxiliary files should be included in a +subdirectory for that bLIP, or must be named bLIP-XXXX-Y.ext, where "XXXX" is the bLIP number, +"Y" is a serial number (starting at 1), and "ext" is replaced by the actual file extension +(e.g. "png"). + +## Licensing + +All bLIPs must be licensed under CC-BY or CC0. + +# History + +This document was derived heavily from [Bitcoin's + BIP-0002](https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki) written by Luke Jr. +which in turn was derived from [Python's PEP-0001](https://www.python.org/dev/peps/). In many +places text was simply copied and modified. Although the PEP-0001 text was written by Barry +Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the +Bitcoin Lightning Improvement Process, and should not be bothered with technical questions +specific to the Lightning Network or the bLIP. Please direct all comments to the bLIP editors. diff --git a/blip-0001/blip-0001-1.png b/blip-0001/blip-0001-1.png new file mode 100644 index 0000000000000000000000000000000000000000..b53279901180a4cb13c1905e053790b290703692 GIT binary patch literal 10389 zcmb7qc{tQ<+yAtnlADNW5t1d@T1c`ck}XPxv4*j4Wz90klC5HtCA;j)kdcuQlS(GC zWgQIe3Ne;Mb~W7E2> zehUWMjRV*9`ZE%ht6?+?vovcA@{+iGF`)NnE-CO`4}t^AKlhYPP1 z94DNAyjpy7`seY7S z@Pv1Va(3r(`BX+jfBk5~syuPUESpiWh91zuTt`hUglq@4B+4acZ;erJgzf$1cT#!j zGj5~E4t7(2mWzJ$Xy+w8ORr;F9R41Ef63f;ugPC^wwiKnmt z!P7le`ifVjVjZ@oh0Y0V+~eb*tIl$DhLUz`J^Id)!SX>FDkXqZL4 zgV7RqcZu%Y>d&6S{qNuUUqvbS&6httYcFQ`eRGM!St&={yT>No!OL51$~ z^A(QWFWkFwuHfh6q#N(D{KYE}gV}s?*>`!OZA$yu>A#Q3I)Ask|97NfcIp}9irJx8 zPVfB_!flCG#Nhq+c!_V;MgtM6i8@mER%ZGXthd`rjmij2& zzx@*~{pC*bDhhSuVXSJ|;)|Q~vF#2_#Z#&V-nQjQg-(hTek7Pa$8$Jwx7J)36YCRd zVB;2zx|(&Mk-k72lQe(b)&BfK3%58z!YM%zCq#T%Rkr3j*4QAd>=w96b~uDozi1pi z`&e%D$m4J8cGP|>VzpJg(i>}5+i^&+?Av2?!Q4(GS<@e09jWKO6~{}HeZH!1>v520 zeU71TmRL3r6gIv;wRn6?c7)Hhbk$ zzXxC_csH|m_yV02f}lq1>qKE4fiw7Pb$A>y z?mblS{=p&G=AZCQ!^7 ziO(u{b5YZ8u^C=(sIS!b__&;ub^S4s-q#}CZ1~wJ5zO2ek+@%8FkSDwz_oZjx8bOR zM?FVI4Qp9$Pl;v+g^?0BZm#i|Fo0@#<8<&y`nqcv^)pYTN=RpF5a?;mxhaHyUMzY;Ew|k7DP4GJkxQUNEfZ zHjICa^rK>Hp*ggDLaDH*A6l((8L&TEtCK8oFU2ajj`F}@7Vk>_f;FiUENnEbaYo8L z)Z|C^(h}fO=7W8eR$~pcnX>&0Ckh)Y8)>Z+?;gF1ppB(&uZj4OOAsI>uC(%*lxUKDGU?+QOW(HHR1>hN9cO9(8Ahk(qa&D?9*8>m z6Bx#F_O`2}gZ1mbA0D55hrOSD*{2lUPu!f4)@qY7!+-v2#t;PS)otJ*yUJ!4zJPFJ z@3shmDN`jRcrAN-Q?$@hE4*VsVgB{0x#a_xcI6_ck=IoW>D5`X*9V?pM(0d#$x{KG zbCuHCh?gYGnf|Hvba-{;Qp3ls(;;QLr5R=Q-NxqkB2Va)Zf5GDj4LhYf*Dk+VT$S; zoZoQ3G7y`|`pI0h41I`fo3QIl|O^RcEZy!kcB?mp+eZ ziN+P?^3+oqGnWr-rmru;Iq3pVMfLG3l?|(=rc>Ni*=WJC`7^QHpIi~IocmfM4A|T( zQNkfZM2F6-e$%pT>{qeW^dx?6edQ@_AtU{>$v&f}i|Ct-A{E9b&qkY5_m!gI$mYj3 z3P%iQ2FiSt3%y0JK86Q$-Z>aWhGUejVfs{b>^5t8#!3m+?;oZL+|DksZ%-2r;_9zW zE30fwt6(z!tbc#DG(PF8w&aDO!v36b_{;UzeYJF}t)-Mz$>6nlO83fet%uwvMfz-Y z9@> zS6o#0&is0lIvTXxo{F1UD_%ZziSH^rAgND6uB3vii5SyyR4dA~C(PWdT~?%-W)`7T z8O@mGMowJcpGC+!?TH#!}kpHT2MX`^buEl`yzTkE#sT-jbe zS?gXJ8;0M`d|j?3bX^Y(9|*sX>2vwyakkLA;&es$xukNJD}&JDtMZ zBtAsd8m`P)PRP8Ka7BaQ_{w8l+p^leJr*yq7fB3mNLuJAiqAA|(vaLYgtu$ssb}Pm z^${f+BdHElR>TT&2O!1OOdW!`m|I_5O7Q<^6k|?_)Wc%MCz7A znhXc&HpjVMrVHX)1aPz{r^&D!j{F%DY@r`|t4*r@b7Rvwig(sF4uJX-hgs&LG1`0n ztvglu>fB=sV#pC?fF}sepQ}$b(Kl+^L)ubgikoG!rm{muTc>^PF0U}=JVL5Jl={pN zi^L+l15L24HUN{59nz&A6zp0L)6v~8H1;o)m=U5~=Q+rEbEe}S!z|sjbrbfd>F=Y< zr7Es$=tVZF)1)ra5~tuQ2D$@>DNR3XX+9E9Mf47=)Lu>`1>9Vrux@UYtm#d?5nQb{ zMnyJ`M8!x_G@=(wbGC{WPiL2AY@aWdrW4Y0d_H+r*k}wVPI$C;9dcb^i!CpVWL-ro z-TKD}nqoLYdmifW8%g1l`$UN2{8xOO>eIIRBDOme7EHFWx;#kt!pYCdxJ98jv$0wk zi2LM!_(> zmzMF&dEGSv)pU}G%k5|@{)>>?u;Kh?t6Ff1h?Tw$?IVm|7O{2>2&;ZuZe;H8C(CFd zahiG7O9*Nh;SIl34EYql+>xei854hwQ_jVd)AU=G*NEE`p+%65L_2LHb(IodGb5bp zJL{aIuM6W^tA{3+T@6sewL?52gd-ecxN^{8f(-bB`m5~`lHQ`v%{GxhJ zJvq+*#$lvSzVV3=5Csf#o|=4%3ANzL(-%hMo(1EK^Qk9Ui^@)*&OjhOP8RkpL(`Q zs=rC2*2zcr*sD`P+4tBUJ(_By&&PfAHNo_GV`eOKl%F|Iu=XEch33@?g=Q^fHYrf6 zN^qq~Qk<^)x|ft6JNV2c$v9lz*l%y}TKyREs9TRK6HN)ZwQ9k-xgu~HciFE7taGtZ zp^wV{8g;@hJ-J*b1DOP&!A1G!96!voaZTd1kJyzaRJtyT-~am|vlNRl#n+*yaLSkx z{*pq81Nhyi|B`jo*`vAnOFj5yihFoKZ@gCco?|kO2?+EtB`iTEOfi~f@6^ztRKrpH z#=VJIQgR$J=L*q$z-YrYkKzR!&s&Cua^KPG!F>+)4&gE70yqK)x4@S_zqH1Zu^vHvI=|^Y$n4T_Za*nM@0UM+;sp-J8ue#_eyuF&xQ-pM&PVKfbG;sjy?K)Jzg-dAK)38}7;0+MRP= z*qSobH-*qi(L{&!-72(wcF?6OwnIT!Q~ja`K&v`=aZF!t%z%ZTMRLpZf--MOr^{F) z8vCelh*O%liEAcw7}nrRjEwG8N;_>ev3{!H`lOEdVQ!4HX#2W9(DD$Syd7=YE>~W% zKk2G0Q&J&k@5mTUh5qK4H;XjR*?-`f=MwiyOkYNM(@1$n>80*x5z13%nEM(8QoZ^b zH0pY%JerF>Af|MF25_jjJm6C*s?Gj3#@yjfy z=c*&vFL%}DCmW)#7-sy)gi>4n zdg&AUCGfcoKZZ%2=emuM%DAGy>VrYitX&wU#3R37{=2R{9eZr}Ign7rADelhg3vqC z3Bk5RKOQMcmG}He9p^us`}rxHg#YQRQy9`^K*t?6rneiOw)v@jrK-DruUo#Oh=BnFb<0*W-0JlnATiX^{zwVoq}~2Uz}VDzJfD($sr~J2 zN6rcmycb3(vQA$<;Ejq6n&t+pPR$WOt{U|2!(Bi-D@>|v=7EH974^V{2bOS{14(KV z1ax^ae>iY;)@eBEuM=r`?rm$-fzBta7^Z(rkI^Hb+ma>m4S;b&R{k@aBqc%mbW!%u z>XQ=+AIq(3oReJ0xB|+kwCSs2m+lvlW_6x+$!OI3S1+SkDpL0l`F#|7ef>P44IdBqIKlEu zQPUlxGDM9Oi>WhEIjG4J$i!Qy_w#ZgTS3M-s=NF~{io`h!dcAZ*%ZZ%D>8-&K4pP` z0=sggJ#qQ?=%_nj%T9eN!JGGoYr(bq;7jXOxzo4uqa~vyb{4M&3J77YLY(*5m3|p` zPk$+htN;0q)y)hfyCb09JWuhP<+loAhpQd*UuB``t93xMcz#KQi|oBx1}PhWW;cV-ax)|j-N&%ij}_{r&-%4zaC8oP5Km+(owP)~@2_-c zrlDsCtIqlGU-l*u&I&;C7ECaml@lq%i3~d{h+DK^g`|zOFFMl5vI5#8FzS2glnq$0CSu_rJ}YcYGLt0p<#Gbou>>BxBe5{M!r%#y4x>q%=+!AO*Vr z`q5o+Bl9xC{awU_`$*rlupu_NC-dxu*DoauYqdz8L)7$6MB{fX<$Gl91drR zg-g$aJnYV%3S5AIS}G%g+1A3BY*%sj?{^n}&K9P-duF3ok>2$Yc&(=*7d6XgbZUd! zjm#=7mCCHJ9mmZ3UpW~m71r&JS<_-l_YI7>hq(k$!+BIVg%pSzEUHL<;ixh{5yyWb8?MS4>N{o zr=`%0GdKV)UVE4iMoUrZ{rvROWUAb_&)mKX6y2RKc6veb|1Z>yB?;nw2e5=db>IKQ z+EC~XtWFaJgaE_g(JI@P)Ri&>)>G09@7)~B?WGaN<0EPM>Mp>!M`DI$2+84vZcYB0 z`TdcsaNiZ`fFF?ToRbCVAcuNQ@S&PAin0Pq6}C5*DdSDyl)v9c*|vhJK9AO`$8c5v zsH*^8GXI`kMVD^U{K~0kHkFn8%y;MB;=g&MEgz9~?^sFI{V-DNn}r|6Zn)*~akzza zQ_r2V`-=&@jwQ(ILaZ4MrS*uUeL&o(^gEA)$@plkoI zOG+ksmFzxHVbKj76cNb}V?<9=R{De8xU!tmVmx zB+Y}k2%PL$~bXE z`OB>$f)CMas^bUk`2`2l4L}9!!CDlt*vzQrB)e2LTr40t=OE5w7*+>O;1LQ7Z+c84 z$NZ;GK>Ho)8i<9w^FUs_u|a;vN9`>!#Ey*Ad2!8jjm!L*aSW5xWZiX?2H-qg_7Vmm z##m}!nX%dim~#`IQd&*`hHW+Sadvt?JLy2|Y`RC|bMNH6D}G9IuX3sYq5CmhwptG~kqOGi6{aU|{m8k+>tU=VZEvuA=bs zMDlb`QGMV-!$78ItJuY)0U#G1rYuaPSmD2QRVjg87k5&^NnhQ>TYXPEsyfnS+a}sl zI-mG|h(2`ji0*=M>20z9H1*AY0#7Uyc+!HjZ-MO0U9$X`Ik)<)VxHSdBRl+Ty873h zu-ef8@j~+;ezM%?{r9r&BZD)^*GscYnNcM=Vfnv+SR0$%2a{ym_mtNqbVyH*@?9BZ zN~yH>yk%W)UV&gBY=C`tQgG{Znwswq@u5By9~0nxl@2^n^zU-Hd*e*GN*vs-VBj{5(i;9EJ}er6!{# zIOqV`MP)J);_4=|6#>jx02H$6S6S&byvXPPNH}{#c>}e!{w==6b-Udo*w%18e>Y~r z<_T$c6+5&v?!J?r3~(((T_gd0>xWe1`q$!6ykocEwP4xW3CY?KP7C<#sbRd^aOza; zSO67!POwbV&Us6xy+lm@guEx}-8taL?X52J+U;>ATHn8EAgJ};(_iQ7rufAD`jHNG zmBg(fyi;r*6d%@@8#*_pvKOFTs1_;bfeN=3mhO8$?#r?`Y)V>7(`XIAwMA%YA|-d4 z!hFrsT%N|s3$lJth9arjMXS#%r?vNwe0+R7?}aJB+i7h)oPCJO!gv4eWMc2r#}QdP z`Adn-D8VxSb6{`oj-CDI)W7?&X7D7{cC(U=3&Pp)N~@_5NGJ6ehATq*7(SfcK=mh& zWNE}6t`fFH`D6r`-UNz%Ui{*1YSn6rfy+BTJw@qzeV14E^Pp+Js*)$i1?2WOwEig4 z)K|SF-}g-=d~&JRYaSF-Zh)`Bt%5NB(PLlB&x{L$qWW2`l@JC6VnvxY9+-(T@nOXt z^ilPdH-t(^d?hXq`klV`#*26v$4#@zjohh}E!O3#)3IUXDK&qH;o{k=1JdN?rhObsO-# z*TzCTeCVBTn|U!zHvBNmwx%Bdze}ax+>l)*B-90> zTTb{5K4QM|F1FlM{~Op+4fuszhVp>tY$xwO;`|J@0Zu7@BR2%rD!o@G0bSZ19RL&} z&p@nG)34_Xjdb_G2K)A7fmSu6GexGE&Fykyt}XD*gK+b^SH5(1tNLgF+8-AVX(gHK-Gn?`aC-KB1&f1G%+~G1-xsZg7K>R~mQa9NU4MnXXkR*g%n(pi^w+@^Z7f zQ`uz#?@n=E!MhA}^t%Y8G2==qEAi4uoKPEdmH zq>k5hP(BJoz(XnknK{=oZsuIgiLCivnqg`k{svG}yz&-9HvIuX&oQ0vuah$LP)o4y z=1~A8NT3x`uAsOn-qmS$QEySf6|qm>oRt76u9-_ykrl@z88{y%n);>7d1NJ%VnO<6hE5|Q*m+ZBoD#KM zQk8KYZx$cAfE`<7m| zz1Wt!$qv3ay2~?VjR(*o80@?@>g4hjXwG-&75Mq@Ux?E|umAfOX91mdk-)?v5AaC* zICHyr+`Vzbehp|ve1;65I(gf*KD!4|jc{hR)~Z`bpzI73>K%us1SU`$;|j7+3y^-h z)-hIxE%L5CHg62t&~=7OnB2YXLj=c45Pt1xvJ`M$WdXmMz{YQrSNH8v8HnO z6zX}^IQQWgMq^)_;~>ov7OKmIg!cXYhMbBttaLVe{qR8WasSbki!bIc@0Ud4KD0^z z5~U${s0>oXd;vFPZK#BkzZB@y|2ZXK#y@%r%Wk%?zW8k}b*3LneaLov5-?0>is&n7 zRf35W!L_H$)t(0$-(7Hk<0A4OiAlH34RlDC&(KHmx`Wl&i+TX65y?aAptnl*f9Cu* z7uhi`R2#%S&vP~b5;(j7BI7-<1s;zK`1Qkj7@YP^nP{%3wcn8HIiG+w2cxW|`pTcP_xA$<+>`pB0W1C9E2O`chb38DV4?D$GTO`jL6w zE|$>+kEB%#LK+Oi_NkSNqz2v*4Jc|YARfeb_z6n3GsJ4I1HgjvN z7X_7{j&>ak0QvigWn>uIwJk|J>UYbrJK|Il2oTKI=SCY8F5l6)g_~>DlxrKt?h~TLa$W82;|fS=O;zkRSjAYc&j;@(To!ilBcI&7M5~m&)iW z@&*#BRLIsQbovE4_O;p-aoK0aM2Sm8_tMurhu+PD>Iw}Pz&>DkS;Qpf#5tP?Hs+on z95}tDw&Ql5c_e0ddqXKt2T+LW*p=4>rh@~5u!R#}-v3L>39opkNEZLxI2{Yd)(j}K zMMJ=f?w1vT2*ARSnZIX6iW9lM@!ORlAq8~!|LW;~{N