From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 16 Mar 2024 11:29:16 -0700 Received: from mail-yb1-f190.google.com ([209.85.219.190]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rlYmQ-0008Ud-V0 for bitcoindev@gnusha.org; Sat, 16 Mar 2024 11:29:16 -0700 Received: by mail-yb1-f190.google.com with SMTP id 3f1490d57ef6-dd1395fd1bfsf5409742276.0 for ; Sat, 16 Mar 2024 11:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1710613749; x=1711218549; 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=zEl9JRVUGgVq8o7bMM+Ep4FVEfYBM8nQFIYsxO4tmtk=; b=SH2+uiNunOXQmY6C49sDdkzS9yJ3nXEUF93OlLzukgwpxRLKgoQw5+HFKX3hSlrp+F ILHCHJNIffNXYIz484kwNBvBp/MEWQFtoOkCT7Xh8r4ZYM2nFJcRIRo2v9YFYFCzWVll K3yj1h0IdfznP1i7BekpZUzLQtTpMVFVEKtPJV/+r54+4wm5MnOn6ONZWIcC/Aq9Rpuq +sEctZmBc5jH55V7MDWLR+EfIySDc4Gtvdm7LVYAKDpJD/KuCNqDARKrp9HGrqxTIHrb oYsOsmyU4bVfDM4zP6Ko18vCav7ya/yh8hVtWh2sPKf7btUC66qPTKyD8UaBy0x42XYs cjWg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710613749; x=1711218549; 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=zEl9JRVUGgVq8o7bMM+Ep4FVEfYBM8nQFIYsxO4tmtk=; b=fQRbFnlOcykpyYDhOOax1//fI8lz2E0DisLNtVCH6olB4kj4Pfp6uiKyWg1/18FZWx 7kiX77BerWEVVQ4dlU6q+5w8oT8of8yLW50PsTVs2ZH7tFGuU0EgHbT6l6oVAQPvEPAE gPEIYvv156BfOYb51aYrjPnRZBtPFUcPuQ9DwMmCCPed7Ibw22t9Nn2yaXNb6wUawZKy 69/mHLyfO8gKpKThuy1T55ekITvId5mPUvAEBfAf+9Da6dvfWIjtWcGIoL8/23qgZWgt pYIOg9lTTDKP6tvenNoEKyHpqH4MFmHAGrUxtbhNFm0LU58yJpxTOcJliJrwm5mjHLAx i35A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710613749; x=1711218549; 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=zEl9JRVUGgVq8o7bMM+Ep4FVEfYBM8nQFIYsxO4tmtk=; b=Xf7UMEQXGfX2nX56tjRpb/Gq2PR1bkFpZbJEgW1QZVNnRz16J0Y0M43bKFEQwUOzV+ c61BzhgMZG3sRgzfrL0V61qXd+A1BwJwUnDBaL/5gWcGbbN5fTT1R50J1+j3fO2/Fq+l o0zee1C6u/5xmy0zWqCOwiM5Aoo1sHXe9vlFCo9NjLDDDnpTvuvNZT3XaEgX3EfBMG1f 5yxJfySEmIdUVLTButXwZl3hJr0edhv4k1gbPh4I7+FscKTqMofcq6Olr/+1Ny7Crf1i WDBqpPCCdcbG09zL55CJOCHUcVAGTYuSuTNs6l4ZDc9razSn35L0L3hVMneZx7pzPeXx zPJg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWqNM+ktfXllIr2dUa4bYVbRtFqA137fbKAZX2K9neWIeRcreM008fFg4mxfKcszQX2OxJ0BTSUK2AueuLYT4s5PH7PMvI= X-Gm-Message-State: AOJu0YzQ1P57pkVPl4DXvV+bGQZEi2xjnoTECQtFm+me1ty7ARO3+pY3 sVD90DVYz7YKkaIOUepzkWFBm1PriqSc6F6pRKxFmHySqrev9MXK X-Google-Smtp-Source: AGHT+IEZMlXva1nf+PUVu83k3OzZkK8Tiy1D+y5ZUThw8CtK7LK94ytRaIxmUuTAHTI5h5zQFIkpbQ== X-Received: by 2002:a25:ab65:0:b0:dcf:afe3:11bf with SMTP id u92-20020a25ab65000000b00dcfafe311bfmr7714589ybi.0.1710613748399; Sat, 16 Mar 2024 11:29:08 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a25:b30d:0:b0:dcc:be89:34e3 with SMTP id l13-20020a25b30d000000b00dccbe8934e3ls960730ybj.1.-pod-prod-05-us; Sat, 16 Mar 2024 11:29:07 -0700 (PDT) X-Received: by 2002:a05:6902:160e:b0:dcf:6b50:9bd7 with SMTP id bw14-20020a056902160e00b00dcf6b509bd7mr1691507ybb.7.1710613746925; Sat, 16 Mar 2024 11:29:06 -0700 (PDT) Received: by 2002:a05:690c:387:b0:60a:5801:5e7b with SMTP id 00721157ae682-60a6aba0a29ms7b3; Sat, 16 Mar 2024 11:21:52 -0700 (PDT) X-Received: by 2002:a05:6902:983:b0:dd9:1db5:8348 with SMTP id bv3-20020a056902098300b00dd91db58348mr35601ybb.8.1710613311219; Sat, 16 Mar 2024 11:21:51 -0700 (PDT) Date: Sat, 16 Mar 2024 11:21:50 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <42adedc4-f3b0-4214-8f0d-2a27a3916fcen@googlegroups.com> In-Reply-To: References: Subject: [bitcoindev] Re: OP_Expire mempool behavior MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_293258_1929047411.1710613310809" X-Original-Sender: antoine.riard@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_293258_1929047411.1710613310809 Content-Type: multipart/alternative; boundary="----=_Part_293259_1485164522.1710613310809" ------=_Part_293259_1485164522.1710613310809 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > > nodes should require higher minimum relay fees for transactions close= =20 to > > their expiration height to ensure we don=E2=80=99t waste bandwidth on= =20 transactions > > that have no potential to be mined I think this concern can be raised on _today_ LN second-stage transactions= =20 (HTLC-preimage / HTLC-timeout), when a HTLC-preimage is broadcast near "cltv_expiry". LN routing nodes will= =20 automatically go to broadcast an on-chain HTLC-timeout transaction. Probabilistically, we're wasting=20 bandwidth on transactions that _might_ have lower odds to be mined. > If you already have a need to make such transactions, you can argue that= =20 the > marginal cost to also use up that bandwidth is low. But that's already=20 the case > with RBF: we allow any transaction to be replaced with RBF for a (by=20 default) > 1sat/vB additional cost to "pay for" the bandwidth of that replacement. > OP_EXPIRE does not change this situation: you're still paying for an=20 additional > 1sat/vB cost over the replaced transaction, as eventually one of your > replacements will get mined. I think yes this is indeed more a replacement issue, nothing new introduced= =20 by OP_EXPIRE finality time-bounding semantics. However, I think it's more an issue if we introduce things like altruistic= =20 re-broadcasting. =20 https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/02218= 8.html =20 Certainly, the re-broadcast could favor transactions with higher odds of=20 being mined, which naively should match RBF rules. And by the same way taking time to answer the open questions on this thread= =20 from the old mailing list: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/02222= 4.html > Are you claiming that BIP157 doesn't work well? In my experience it does.= =20 I've not checked recently, though from research memory a while back the=20 numbers of BIP157 services offering peers was in the range of ~10 / 100. One can check by collecting nVersions messages from peers with=20 `NODE_COMPACT_FILTERS`. > Huh? Bitcoin nodes almost always use the same mempool limit, 300MB, so=20 mempool min fees are very consistent across nodes. I just checked four=20 different long running > nodes I have access to, running a variety of=20 Bitcoin Core versions on different platforms and very different places in= =20 the world, and their minfees all agree to well within 1% > In fact, they= =20 agree on min fee much *more* closely than the size of their mempools (in=20 terms of # of transactions). Which makes sense when you think about it, as= =20 the > slope of the supply/demand curve is fairly flat right now. See https://github.com/bitcoin/bitcoin/pull/28488 which is motivated from= =20 diverging mempool min fees from the ground iirc. > From the point of view of a single node, an attacker can not reuse a UTXO= =20 in a replacement cycling attack. The BIP125 rules, in particular rule #4,= =20 ensure that each > replacement consumes liquidity because each replacement requires a higher= =20 fee, at least high enough to "pay for" the bandwidth of the replacement. An= =20 attacker trying to > use the same UTXO's to cycle out multiple victim=20 transactions has to pay a higher fee for each victim cycled out. This is=20 because at each step of the cycle, the attacker had > to broadcast a=20 transaction with a higher fee than some other transaction. This does not stay true with nVersion=3D3, where a package parent can be=20 signed with a feerate under min relay tx fee. See the second test attached in the initial full=20 report email on replacement cycling attacks, one can replace the child of the package and the parent is= =20 automatically evicted,=20 without the "pay for" bandwidth of the replacement fully covered. This is correct there is a minimal fee basis for each additional victim=20 cycled out, while one can get a very advantageous scaling effect by RC'ing the child txn. > If I understand correctly, here you are talking about an attacker with=20 connections to many different nodes at once, using the same UTXO(s) to do= =20 replacement cycling > attacks against different victim transactions on many different nodes at= =20 once. > There is no free lunch in this strategy. By using the same UTXO(s)=20 against multiple victims, > the attacker dramatically reduces the effectiveness of the attack because= =20 only a subset of nodes see each "side" of the attack. The attacker assumptions is correct and relies on partitioning mempools.=20 However, I disagree on the reduction in attack effectiveness as traditional LN nodes have only= =20 one tx-relay edge access to the tx-relay network (and LN nodes interfaces are a clusterfuck to do it= =20 correctly here). > Suppose that Mallory is connected directly or indirectly Alice and Bob's= =20 nodes, and attempts to do a replacement cycling attack against both Alice= =20 and Bob with the same > UTXO(s). > Both Alice and Bob's victim transactions spend different UTXOs, so every= =20 node on the network can add both transactions to their mempool. When Alice= =20 and Bob > broadcast their victim transactions, their nodes will tell multiple=20 peers about their respective transactions. Indeed, if alturistic=20 rebroadcasting is to be relevant at all, nodes > other than Alice and Bob's= =20 *must* have learned about their transactions! > Mallory on the other hand is creating divergent attack transactions that= =20 are mututally > incompatible. When Mallory broadcasts those attack transactions, from the= =20 perspective of some nodes, Alice's victim transaction will be replaced out= =20 but not Bob's, and > from the perspective of other nodes, the opposite. I'm assuming Mallory is partitioning Alice and Bob's local mempool from the= =20 rest of the network by using.2 distinct UTXOs. However their victim transactions won't=20 propagate out of their local mempools due to Mallory's higher / higher feerate conflicting=20 transactions. Mallory won't have to paid the fan-out of 3.125 BTC of concurrent replacement, assuming the=20 partitioning isolation from the rest of the network is well-done. > Indeed, from the perspective of roughly half of the alturistic=20 rebroadcasting nodes, Alice's transaction was never cycled out, and the=20 other half, Bob's was never cycled out! > Even in this case where the attack only used the same UTXO for two=20 targets, each victim transaction gets to roughly 50% of the mining nodes,= =20 making the attack > ineffective. And the numbers for Mallory just keep getting worse as he=20 targets more victims at once. I think you can just use one UTXO for each RC target by broadcasting a=20 transaction in the target local mempool's conflicting constantly with the malicious replacement transaction= . >From my understanding, altruistic rebroadcasting only introduces the=20 encumbrance on the attacker to add 1 UTXO per-victim's local mempool. I believe it's small advance to=20 mitigate replacement cycling attacks, however a very cheap one given the marginal cost of a UTXO. Best, Antoine Le mercredi 13 mars 2024 =C3=A0 05:10:40 UTC, Peter Todd a =C3=A9crit : > I got a question re: the following comment on delvingbitcoin with regard = to > OP_Expire: > > > > nodes should require higher minimum relay fees for transactions close= =20 > to > > > their expiration height to ensure we don=E2=80=99t waste bandwidth on= =20 > transactions > > > that have no potential to be mined > > > > This seems insufficient to solve the problem, unless the premium is so= =20 > high > > that it virtually guarantees that the transaction will be mined before = it > > expires. However, if the feerate were that high, wouldn=E2=80=99t OP_EX= PIRE=20 > simply > > waste blockspace? If however the feerate of the transaction is merely > > competitive, the presence of OP_EXPIRE creates a bandwidth-wasting=20 > vector: an > > attacker would submit e.g. OP_EXPIRE transactions at the bottom of the= =20 > top > > block and push them out of the top block with further OP_EXPIRE=20 > transactions. > > This way the attacker could issue a constant stream of transactions, bu= t > > never pay for more than a couple barely sliding in at the bottom of the > > block. > -https://delvingbitcoin.org/t/op-checkmaxtimeverify/581/8 > > This "bandwidth-wasting vector" requires the attacker to create actual > fee-paying transactions, with a fee-rate sufficiently high to get mined i= n=20 > the > next block or so. This of course is very expensive by itself. > > If you already have a need to make such transactions, you can argue that= =20 > the > marginal cost to also use up that bandwidth is low. But that's already th= e=20 > case > with RBF: we allow any transaction to be replaced with RBF for a (by=20 > default) > 1sat/vB additional cost to "pay for" the bandwidth of that replacement. > OP_EXPIRE does not change this situation: you're still paying for an=20 > additional > 1sat/vB cost over the replaced transaction, as eventually one of your > replacements will get mined. > > --=20 > https://petertodd.org 'peter'[:-1]@petertodd.org > --=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/42adedc4-f3b0-4214-8f0d-2a27a3916fcen%40googlegroups.com. ------=_Part_293259_1485164522.1710613310809 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > > nodes should require higher minimum relay fees for transacti= ons close to
> > their expiration height to ensure we don=E2=80= =99t waste bandwidth on transactions
> > that have no potential = to be mined

I think this concern can be raised on _tod= ay_ LN second-stage transactions (HTLC-preimage / HTLC-timeout),
= when a HTLC-preimage is broadcast near "cltv_expiry". LN routing nodes will= automatically go to broadcast an
on-chain HTLC-timeout transacti= on. Probabilistically, we're wasting bandwidth on transactions that _might_= have
lower odds to be mined.

> If = you already have a need to make such transactions, you can argue that the> marginal cost to also use up that bandwidth is low. But that's alr= eady the case
> with RBF: we allow any transaction to be replaced w= ith RBF for a (by default)
> 1sat/vB additional cost to "pay for" t= he bandwidth of that replacement.
> OP_EXPIRE does not change this = situation: you're still paying for an additional
> 1sat/vB cost ove= r the replaced transaction, as eventually one of your
> replacement= s will get mined.

I think yes this is inde= ed more a replacement issue, nothing new introduced by OP_EXPIRE finality t= ime-bounding semantics.
However, I think it's more an issue if we= introduce things like altruistic re-broadcasting.
=C2=A0
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/02= 2188.html
=C2=A0
Certainly, the re-broadcast could favo= r transactions with higher odds of being mined, which naively should match = RBF rules.

And by the same way taking time to an= swer the open questions on this thread from the old mailing list:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/0222= 24.html

> Are you claiming that BIP157 doesn't wor= k well? In my experience it does.

I've not checked recently, though from research memory a while= back the numbers of BIP157 services offering peers
was in the ra= nge of ~10 / 100.

One can check by collecting nV= ersions messages from peers with `NODE_COMPACT_FILTERS`.

&g= t; Huh? Bitcoin nodes almost always use the same mempool limit, 300MB, so m= empool min fees are very consistent across nodes. I just checked four different lo= ng running > nodes I have access to, running a variety of Bitcoin Core vers= ions on different platforms and very different places in the world, and their minfe= es all agree to well within 1% =C2=A0> In fact, they agree on min fee much = *more* closely than the size of their mempools (in terms of # of transactions). Which makes sense when you think about it, as the
> slope of the supply/demand curve is fairly flat= right now.

See https://github.com/= bitcoin/bitcoin/pull/28488 which is motivated from diverging mempool min fe= es from the ground iirc.

> From the point of view of a s= ingle node, an attacker can not reuse a UTXO in a replacement cycling attack. The BIP125 rules, in particular rule #4, ensure that each
> replacement consumes liquidity because each replacemen= t requires a higher fee, at least high enough to "pay for" the bandwidth of the replacem= ent. An attacker trying to > use the same UTXO's to cycle out multiple victim transactions has to pay a higher fee for each victim cycled out. This is because at each step of the cycle, the attacker had > to broadcast a tra= nsaction with a higher fee than some other transaction.

This does not stay true with nVersion=3D3, where a package pare= nt can be signed with a feerate
under min relay tx fee. See the s= econd test attached in the initial full report email on replacement
cycling attacks, one can replace the child of the package and the parent= is automatically evicted,=C2=A0
without the "pay for" bandwidth = of the replacement fully covered.

This is correc= t there is a minimal fee basis for each additional victim cycled out, while= one can get
a very advantageous scaling effect by RC'ing the chi= ld txn.

> If I understand correctly, here you are talkin= g about an attacker with connections to many different nodes at once, using the same UTXO(s) to do replacement cycling
> attacks against different victim transaction= s on many different nodes at once.

> There is no free lunch in = this strategy. By using the same UTXO(s) against multiple victims,
> the attacker dramatically reduces the effectiv= eness of the attack because only a subset of nodes see each "side" of the attack.=
=
The attacker assumptions is correct and relies on partition= ing mempools. However, I disagree
on the reduction in attac= k effectiveness as traditional LN nodes have only one tx-relay edge access<= /span>
to the tx-relay network (and LN nodes interfaces are a clus= terfuck to do it correctly here).

= > Suppos= e that Mallory is connected directly or indirectly Alice and Bob's nodes, and attempts to do a replacement cycling attack against both Alice and Bob = with the same
> UTXO(s).

> Both Alice and Bob's v= ictim transactions spend different UTXOs, so every node on the network can add both transactions to their mempool. When Alice and B= ob
> =C2=A0broadcast their victim transactions, their nodes will t= ell multiple peers about their respective transactions. Indeed, if alturistic rebroadcasting is to b= e relevant at all, nodes > other than Alice and Bob's *must* have learned = about their transactions!

> Mallory on the other hand is cr= eating divergent attack transactions that are mututally
> incompatible. When Mallory broadcasts those atta= ck transactions, from the perspective of some nodes, Alice's victim transaction will be replaced = out but not Bob's, and
> from the perspective of other nodes, the oppo= site.

I'm= assuming Mallory is partitioning Alice and Bob's local mempool from the re= st of the network
by using.2 disti= nct UTXOs. However their victim transactions won't propagate out of their l= ocal
mempools due to Mallory's =C2= =A0higher / higher feerate conflicting transactions. Mallory won't have to<= /font>
paid the fan-out of 3.125 BTC of c= oncurrent replacement, assuming the partitioning isolation from
the rest of the network is well-done.<= /div>

> Indeed, from the perspe= ctive of roughly half of the alturistic rebroadcasting nodes, Alice's transaction was never cycled out, and the other half, Bob's = was never cycled out!

> Even in this case where the attac= k only used the same UTXO for two targets, each victim transaction gets to roughly 50% of the mining nodes, making the attack
> ineffective. And the numbers for Mallory just keep gettin= g worse as he targets more victims at once.
I think you can just use one UTXO for each RC target by broad= casting a transaction in the target local
mempool's conflic= ting constantly with the malicious replacement transaction.

From my understandi= ng, altruistic rebroadcasting only introduces the encumbrance on the attack= er to
add 1 UTXO per-victim's local mempool. I believe it's small adv= ance to mitigate replacement cycling attacks,
however a very chea= p one given the marginal cost of a UTXO.

Best,
Antoine

Le mercredi 13 mars 2024 =C3=A0 05:10:40 UT= C, Peter Todd a =C3=A9crit=C2=A0:
I got a question re: the following comment on delvingb= itcoin with regard to
OP_Expire:

> > nodes should require higher minimum relay fees for transactio= ns close to
> > their expiration height to ensure we don=E2=80=99t waste band= width on transactions
> > that have no potential to be mined
>
> This seems insufficient to solve the problem, unless the premium i= s so high
> that it virtually guarantees that the transaction will be mined be= fore it
> expires. However, if the feerate were that high, wouldn=E2=80=99t = OP_EXPIRE simply
> waste blockspace? If however the feerate of the transaction is mer= ely
> competitive, the presence of OP_EXPIRE creates a bandwidth-wasting= vector: an
> attacker would submit e.g. OP_EXPIRE transactions at the bottom of= the top
> block and push them out of the top block with further OP_EXPIRE tr= ansactions.
> This way the attacker could issue a constant stream of transaction= s, but
> never pay for more than a couple barely sliding in at the bottom o= f the
> block.
-https://delvingbitcoin.org/t/op-checkmaxtimeverify/581/8=

This "bandwidth-wasting vector" requires the attacker to crea= te actual
fee-paying transactions, with a fee-rate sufficiently high to get mined= in the
next block or so. This of course is very expensive by itself.

If you already have a need to make such transactions, you can argue tha= t the
marginal cost to also use up that bandwidth is low. But that's alre= ady the case
with RBF: we allow any transaction to be replaced with RBF for a (by de= fault)
1sat/vB additional cost to "pay for" the bandwidth of that re= placement.
OP_EXPIRE does not change this situation: you're still paying for a= n additional
1sat/vB cost over the replaced transaction, as eventually one of your
replacements will get mined.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/42adedc4-f3b0-4214-8f0d-2a27a3916fcen%40googlegroups.com.=
------=_Part_293259_1485164522.1710613310809-- ------=_Part_293258_1929047411.1710613310809--