path: root/b8/2ab056a9f1be10ba02ac2e7f65999aa91dec04

Delivery-date: Fri, 02 May 2025 12:11:28 -0700
Received: from mail-yb1-f184.google.com ([209.85.219.184])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCU2P6FJ3EBBBVNR2TAAMGQERF2KRGI@googlegroups.com>)
	id 1uAvnC-0001Ji-SH
	for bitcoindev@gnusha.org; Fri, 02 May 2025 12:11:28 -0700
Received: by mail-yb1-f184.google.com with SMTP id 3f1490d57ef6-e5b0f2778d6sf3523213276.3
        for <bitcoindev@gnusha.org>; Fri, 02 May 2025 12:11:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1746213081; x=1746817881; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=RdxH6pSXJG4Cm1QFVloyhXecShnpqNfHDn+KHEZ27zw=;
        b=iaSsrFfNZkqrjM8+NFhZx+pCFAGU4skax3rfK3fLp5AcxBGAV5VZn79ceSKURCijLk
         4q1QrfHzUfj0tf4r8fnMMLf0FiJOdoUW+9pF+kD5cuPy5zb5vUqZhiiP5d7QrlIL+Cq8
         TbNyBZ2IhhyZPknjKPJRqZqqT9XZBjQ+EsJ2fZRfC6Ay8IP8BzVDHsDCu12RMcEyG8iP
         4SxwFzhg+2zMLShBLlZsj4ghiMN2qx2JzJHjyehaRrGA9sC8QvQaP/vRH4aV4ajE7Cqr
         1IAc0hiet/JZIgxGKjQZKSkUFtnymMurl4VlNocQG4uGhuNX9MyNuikG8AnQzvJUQjlN
         4iuA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746213081; x=1746817881; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=RdxH6pSXJG4Cm1QFVloyhXecShnpqNfHDn+KHEZ27zw=;
        b=WbsLYgvwSojc3wITI8A9tPFNNMD3vqd6f9eRcR8hBVii2cOsjVfAoqWGYu9jsm7MGE
         k9rF2HmCVLHNnMyC9L21acEbmpkfBVVBWmuPsDPBKsZ2bBbV6GPETR3KMjdI1ssU3MEW
         T7greN0sbqpmkd/I4kkViwz+cR7LncG0H/w93oMKnrXGu8ztCN2ryJVisQEe78vF9Q43
         vQrYpb2ez1ode3M4ARbKKefzusAc+7oBd+bqu4e2q2k4yAoIJkrvtXBkr77qJnVLsCyI
         q23mOX0Pq/yXV78wbd8S7k1u1ven4Gi1gkc44IkBGjdY7mzIAnI3sJdgviTxBGXLgPKE
         pocw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746213081; x=1746817881;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=RdxH6pSXJG4Cm1QFVloyhXecShnpqNfHDn+KHEZ27zw=;
        b=hABfEnGioeNTAm+4Krfw4uxrgEFSo2wPN82w9lI240cL9WXjvpFc3PSJ/ys+qa+l88
         mC/2c2lSN7SnK5Bd3tlsf7zQinQDKPrgq/XmKFZiZAf2vUBW7raJ7teo7fHXglmCpdTH
         LN5yBoYoeAGomjYHL/Fu466x5j+73MBg3GfqUekyVG1gpAw31Q1lJ0r45gubz/SOBauI
         IYLtsaW0awr6Qw8toRRZP9OUxbJVQ2bTXFY2xVoD25ewz4XY9EKWsxGaaoE8/PLDkSAB
         fuMUzx45RYFmkoq8kfpKIwu3qCC4mqecf30uxUuhCQaLg4kgBPOfTi9d1qCP7rjIyHOP
         553Q==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCX3CtHHAhljTNXqlNq4GPH33NuD+GbCEI+LAcnvGGBDMy+lpf2Jx8tlJCXWw2aimBJNxSC+ntEnqxWq@gnusha.org
X-Gm-Message-State: AOJu0YzP7tWZOp1MB9xmSJeV/kIR/thirLYi2svAaO0kNxDA5s4bDUlj
	Z/g5P6Du32QoF07rZK62kt3bldSakaMqF4yI0TcZWm4V3pOTuV3m
X-Google-Smtp-Source: AGHT+IHks0BBLe/vB5miJm+M0cu0oiLDrHKPAPBQez/EHSEyCENaNfkjtMBSVcVIzcl6x0uWutQvfg==
X-Received: by 2002:a05:6902:2484:b0:e73:3239:9328 with SMTP id 3f1490d57ef6-e756556fb4bmr5320313276.18.1746213080965;
        Fri, 02 May 2025 12:11:20 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBF3gyi3OQrxXVNfLrVKDbe43Ep4V8cy1UK4kTwTZJMRUg==
Received: by 2002:a25:ceca:0:b0:e5b:3877:6d59 with SMTP id 3f1490d57ef6-e74d9b7ccb1ls739072276.0.-pod-prod-05-us;
 Fri, 02 May 2025 12:11:17 -0700 (PDT)
X-Received: by 2002:a05:690c:c1e:b0:707:48a7:ea74 with SMTP id 00721157ae682-708ced71441mr61446137b3.22.1746213077210;
        Fri, 02 May 2025 12:11:17 -0700 (PDT)
Received: by 2002:a81:f801:0:b0:6ef:590d:3213 with SMTP id 00721157ae682-708cfb0b4cems7b3;
        Fri, 2 May 2025 12:04:15 -0700 (PDT)
X-Received: by 2002:a05:690c:9c09:b0:6f5:2793:2897 with SMTP id 00721157ae682-708cede52a1mr63044547b3.30.1746212653775;
        Fri, 02 May 2025 12:04:13 -0700 (PDT)
Date: Fri, 2 May 2025 12:04:13 -0700 (PDT)
From: /dev /fd0 <alicexbtong@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <47454755-7c6c-458b-9545-8c8657b640f1n@googlegroups.com>
In-Reply-To: <9c50244f-0ca0-40a5-8b76-01ba0d67ec1bn@googlegroups.com>
References: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com>
 <9c50244f-0ca0-40a5-8b76-01ba0d67ec1bn@googlegroups.com>
Subject: [bitcoindev] Re: Relax OP_RETURN standardness restrictions
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_104504_590750689.1746212653410"
X-Original-Sender: alicexbtong@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

------=_Part_104504_590750689.1746212653410
Content-Type: multipart/alternative; 
	boundary="----=_Part_104505_1689129783.1746212653410"

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

Hi Greg,

> Some Bitcoiners are of the opinion that they still want a knob, I think=
=20
doing so is a disrespectful placebo[*] but I don't have a strong opinion if=
=20
an option remains--=20
> the code is safer and cleaner without some filtering rules that few users=
=20
would use but that really just a question between software maintainers and=
=20
users.
> That said, Bitcoin core has generally not had knobs to adjust relay=20
policy as distinct from mining policy in large part because of the design=
=20
assumption that the
> two need to be the same.  But in this case if there were a knob here I=20
think would make more sense for it to control mining policy rather than=20
relay policy,
> since it would actually have some effect in the mining context (in=20
excluding the txn from your own blocks) while as a relay only thing it is=
=20
impotent.

Config `mempoolfullrbf` was added in July 2022:=20
https://github.com/bitcoin/bitcoin/pull/25353
It was made default in August 2024:=20
https://github.com/bitcoin/bitcoin/pull/30493
Option was removed in November 2024:=20
https://github.com/bitcoin/bitcoin/pull/30592

`datacarrier` and `datacarriersize` already exist, so why is it a big deal=
=20
to remove them after a few months of monitoring the usage with stats?=20

/dev/fd0
floppy disk guy

On Friday, May 2, 2025 at 12:17:40=E2=80=AFPM UTC+5:30 Greg Maxwell wrote:

> On Thursday, April 17, 2025 at 7:09:23=E2=80=AFPM UTC Antoine Poinsot wro=
te:
>
>
> Since the restrictions on the usage of OP_RETURN outputs encourage harmfu=
l=20
> practices while being ineffective in deterring unwanted usage, i propose =
to=20
> drop them.=20
>
>
> The situation is even somewhat worse than that:  There are a number of=20
> design decisions where it's generally assumed that relay and mining polic=
y=20
> generally match, or at least that mismatches are short lived.
>
> When relay policy is more restrictive than what is actually being mined=
=20
> there are at least two serious negative effects.
>
> The first is that the latency of block propagation is greatly harmed,  a=
=20
> single missed transaction causes a tripling of the per hop transmission=
=20
> delay.  If the missed transaction(s) are larger than the TCP window then=
=20
> the increase may be many round trip times.  Also if the missed data is=20
> large the currently unused prefill mechanism in compact blocks wouldn't=
=20
> help (and would instead likely make things worse as then nodes will get=
=20
> several times the same transaction data from different peers and you cann=
ot=20
> decode the compact block until all the prefill data has been received due=
=20
> to the message checksum.  Delays in block propagation can have a=20
> disproportionate effect on mining centralization because they cause large=
r=20
> miners to have improved profitability over smaller ones. This happens=20
> regardless of which party was on which side of the delay, no matter which=
=20
> side is delayed its the smaller miner's expected profits that are=20
> diminisned and the nature of mining competition means that less profitabl=
e=20
> miners go bankrupt.
>
> This also encourages the establishment of direct miner submission which=
=20
> can undermine the permissionless nature of bitcoin and in particular agai=
n=20
> shifts profits towards larger miners because e.g. few would bother=20
> connecting to a 1% miner's direct submission interface (if they could eve=
n=20
> afford to make one).
>
> There are also a number of less significant harms, e.g. more restrictive=
=20
> relay policy makes fee estimation less accurate/complete (though at least=
=20
> estimation is designed to be fairly robust in that direction).=20
>
> So on this basis I suggest a principle for these sorts of policy:   Relay=
=20
> rules should admit all transactions which are reliably being mined.
>
> I think node software should adopt this principal as a general rule.
>
> Admitting the transactions is not endorsing them, it's just a recognition=
=20
> of reality.  This policy or equivalent is also the requirement to not=20
> suffer from the downsides of relay being more restrictive than mining.   =
If=20
> we imagine that a miner is mining some kind of harmful attack transaction=
=20
> e.g. a validation DOS attack, then the miner needs to be convinced to sto=
p,=20
> the implementation changed to not have bad performance, and/or consensus=
=20
> rules must be changed ... but relay policy can't address it.
>
> By general rule I mean that should something like a miner begin mining=20
> e.g. quadratic hashing bloat legacy txn, or using unused=20
> opcode/successcode/version number or whatever by mistake or technical=20
> ignorance there is no need to rush off enabling their relay. A general ru=
le=20
> isn't a suicide pact.  But if it were the case that transactions misusing=
 a=20
> particular forward compatibility feature were reliably getting mined then=
=20
> that feature would just no longer be useful for forward compatibility=20
> regardless of what relay policy says about it and it would be better to=
=20
> relay them than have the downsides of not doing so.
>
> As Antoine Poinsot points out, the existent rule is entirely ineffectual:=
 =20
> Parties current bypass these rules with other transaction forms (such as=
=20
> very harmful address stuffing which is impossible to block) or by direct=
=20
> miner submission, which will continue considering the millions of dollars=
=20
> miners have received mining transactions with violate the relay rules. =
=20
> Because of this it will not become effectual with time or tweaking.  It i=
s=20
> a dead parrot^policy.  This is no surprise, since it's a product of=20
> Bitcoin's anti-censorship properties that *generally* filtering will not=
=20
> work except on the fringes.  As such there isn't practical upside to=20
> keeping filtering beyond what miners currently perform.=20
>
> Some Bitcoiners are of the opinion that they still want a knob, I think=
=20
> doing so is a disrespectful placebo[*] but I don't have a strong opinion =
if=20
> an option remains-- the code is safer and cleaner without some filtering=
=20
> rules that few users would use but that really just a question between=20
> software maintainers and users.  That said, Bitcoin core has generally no=
t=20
> had knobs to adjust relay policy as distinct from mining policy in large=
=20
> part because of the design assumption that the two need to be the same. =
=20
> But in this case if there were a knob here I think would make more sense=
=20
> for it to control mining policy rather than relay policy, since it would=
=20
> actually have some effect in the mining context (in excluding the txn fro=
m=20
> your own blocks) while as a relay only thing it is impotent.
> =20
>
> [*] It doesn't even conserve their resources meaningfully.  They'll still=
=20
> receive and process the txn, then discard.  Then they likely have to fetc=
h=20
> it a second time when it shows up in a block.  Although they may save=20
> re-transmitting it, on average network wide each transaction is sent once=
=20
> and received once so the extra transmission for the block should offset t=
he=20
> relay savings.
>
>
>
>

--=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 visit https://groups.google.com/d/msgid/bitcoindev/=
47454755-7c6c-458b-9545-8c8657b640f1n%40googlegroups.com.

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

Hi Greg,<div><br /></div><div>&gt;=C2=A0Some Bitcoiners are of the opinion =
that they still want a knob, I think doing so is a disrespectful placebo[*]=
 but I don't have a strong opinion if an option remains--=C2=A0</div><div>&=
gt; the code is safer and cleaner without some filtering rules that few use=
rs would use but that really just a question between software maintainers a=
nd users.</div><div>&gt; That said, Bitcoin core has generally not had knob=
s to adjust relay policy as distinct from mining policy in large part becau=
se of the design assumption that the</div><div>&gt; two need to be the same=
. =C2=A0But in this case if there were a knob here I think would make more =
sense for it to control mining policy rather than relay policy,</div><div>&=
gt; since it would actually have some effect in the mining context (in excl=
uding the txn from your own blocks) while as a relay only thing it is impot=
ent.<br /><br />Config `mempoolfullrbf` was added in July 2022:=C2=A0<a hre=
f=3D"https://github.com/bitcoin/bitcoin/pull/25353">https://github.com/bitc=
oin/bitcoin/pull/25353</a><br />It was made default in August 2024:=C2=A0<a=
 href=3D"https://github.com/bitcoin/bitcoin/pull/30493">https://github.com/=
bitcoin/bitcoin/pull/30493</a><br />Option was removed in November 2024:=C2=
=A0<a href=3D"https://github.com/bitcoin/bitcoin/pull/30592">https://github=
.com/bitcoin/bitcoin/pull/30592</a><br /><br />`datacarrier` and `datacarri=
ersize` already exist, so why is it a big deal to remove them after a few m=
onths of monitoring the usage with stats?=C2=A0</div><div><br /></div><div>=
/dev/fd0</div><div>floppy disk guy<br /><br /></div><div class=3D"gmail_quo=
te"><div dir=3D"auto" class=3D"gmail_attr">On Friday, May 2, 2025 at 12:17:=
40=E2=80=AFPM UTC+5:30 Greg Maxwell wrote:<br/></div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 2=
04, 204); padding-left: 1ex;"><div><div dir=3D"auto">On Thursday, April 17,=
 2025 at 7:09:23=E2=80=AFPM UTC Antoine Poinsot wrote:<br></div><blockquote=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex"><br><div style=3D"font-family:Arial,sans-serif;font-size:1=
4px">Since
 the restrictions on the usage of OP_RETURN outputs encourage harmful=20
practices while being ineffective in deterring unwanted usage, i propose
 to drop them. <br></div></blockquote><div><br></div></div><div><div>The si=
tuation=20
is even somewhat worse than that:=C2=A0 There are a number of design=20
decisions where it&#39;s generally assumed that relay and mining policy=20
generally match, or at least that mismatches are short lived.</div><div><br=
></div><div>When relay policy is more restrictive than what is actually bei=
ng mined there are at least two serious negative effects.</div><div><br></d=
iv><div>The
 first is that the latency of block propagation is greatly harmed,=C2=A0 a=
=20
single missed transaction causes a tripling of the per hop transmission=20
delay.=C2=A0 If the missed transaction(s) are larger than the TCP window th=
en
 the increase may be many round trip times.=C2=A0 Also if the missed data i=
s=20
large the currently unused prefill mechanism in compact blocks wouldn&#39;t=
=20
help (and would instead likely make things worse as then nodes will get=20
several times the same transaction data from different peers and you=20
cannot decode the compact block until all the prefill data has been=20
received due to the message checksum.=C2=A0 Delays in block propagation can=
=20
have a disproportionate effect on mining centralization because they=20
cause larger miners to have improved profitability over smaller ones.=20
This happens regardless of which party was on which side of the delay,=20
no matter which side is delayed its the smaller miner&#39;s expected profit=
s
 that are diminisned and the nature of mining competition means that=20
less profitable miners go bankrupt.</div><div><br></div><div>This also=20
encourages the establishment of direct miner submission which can=20
undermine the permissionless nature of bitcoin and in particular again=20
shifts profits towards larger miners because e.g. few would bother=20
connecting to a 1% miner&#39;s direct submission interface (if they could=
=20
even afford to make one).</div><div><br></div><div>There are also a=20
number of less significant harms, e.g. more restrictive relay policy=20
makes fee estimation less accurate/complete (though at least estimation=20
is designed to be fairly robust in that direction). <br></div><div><br></di=
v><div>So
 on this basis I suggest a principle for these sorts of policy:=C2=A0=C2=A0=
 Relay=20
rules should admit all transactions which are reliably being=20
mined.</div><div><br></div><div>I think node software should adopt this pri=
ncipal as a general rule.</div><div><br></div><div>Admitting the transactio=
ns is not=20
endorsing them, it&#39;s just a recognition of reality.=C2=A0 This policy o=
r=20
equivalent is also the requirement to not suffer from the downsides of=20
relay being more restrictive than mining.=C2=A0=C2=A0 If we imagine that a =
miner=20
is mining some kind of harmful attack transaction e.g. a validation DOS=20
attack, then the miner needs to be convinced to stop, the implementation
 changed to not have bad performance, and/or consensus rules must be=20
changed ... but relay policy can&#39;t address it.</div><div><br></div><div=
>By general rule I mean that should something like a miner begin mining e.g=
. quadratic hashing bloat legacy txn, or using unused opcode/successcode/ve=
rsion number or whatever by mistake or technical ignorance there is no need=
 to rush off enabling their relay. A general rule isn&#39;t a suicide pact.=
=C2=A0 But if it were the case that transactions misusing a particular forw=
ard compatibility feature were reliably getting mined then that feature wou=
ld just no longer be useful for forward compatibility regardless of what re=
lay policy says about it and it would be better to relay them than have the=
 downsides of not doing so.</div><div><br></div><div>As
 Antoine Poinsot points out, the existent rule is entirely ineffectual:=C2=
=A0
 Parties current bypass these rules with other transaction forms (such=20
as very harmful address stuffing which is impossible to block) or by=20
direct miner submission, which will continue considering the millions of
 dollars miners have received mining transactions with violate the relay
 rules.=C2=A0 Because of this it will not become effectual with time or=20
tweaking.=C2=A0 It is a dead parrot^policy.=C2=A0 This is no surprise, sinc=
e it&#39;s a
 product of Bitcoin&#39;s anti-censorship properties that *generally*=20
filtering will not work except on the fringes.=C2=A0 As such there isn&#39;=
t=20
practical upside to keeping filtering beyond what miners currently=20
perform. <br></div><div><br></div><div>Some Bitcoiners are of the=20
opinion that they still want a knob, I think doing so is a disrespectful
 placebo[*] but I don&#39;t have a strong opinion if an option remains-- th=
e code is safer and=20
cleaner without some filtering rules that few users would use but that=20
really just a question between software maintainers and users.=C2=A0 That=
=20
said, Bitcoin core has generally not had knobs to adjust relay policy as
 distinct from mining policy in large part because of the design=20
assumption that the two need to be the same.=C2=A0 But in this case if ther=
e=20
were a knob here I think would make more sense for it to control mining=20
policy rather than relay policy, since it would actually have some=20
effect in the mining context (in excluding the txn from your own blocks) wh=
ile as a relay only thing it is impotent.</div><div>=C2=A0</div></div><br><=
div>[*] It doesn&#39;t even conserve their resources meaningfully.=C2=A0 Th=
ey&#39;ll still receive and process the txn, then discard.=C2=A0 Then they =
likely have to fetch it a second time when it shows up in a block.=C2=A0 Al=
though they may save re-transmitting it, on average network wide each trans=
action is sent once and received once so the extra transmission for the blo=
ck should offset the relay savings.</div><div><br></div><div><br></div><div=
><br></div></blockquote></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 visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/47454755-7c6c-458b-9545-8c8657b640f1n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/47454755-7c6c-458b-9545-8c8657b640f1n%40googlegroups.com</a>.<br />

------=_Part_104505_1689129783.1746212653410--

------=_Part_104504_590750689.1746212653410--