Delivery-date: Sat, 26 Oct 2024 02:05:32 -0700
Sender: bitcoindev@googlegroups.com
Date: Fri, 25 Oct 2024 07:49:02 -0700 (PDT)
From: waxwing/ AdamISZ <ekaggata@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <77ad84ed-2ff8-4929-b8da-d940c95d18a7n@googlegroups.com>
In-Reply-To: <b0f40eab-42f3-4153-8083-b455fbd17e19n@googlegroups.com>
References: <b0f40eab-42f3-4153-8083-b455fbd17e19n@googlegroups.com>
Subject: [bitcoindev] Re: BIP: DLEQ
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_74722_461499448.1729867742479"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_74722_461499448.1729867742479
Content-Type: multipart/alternative; 
	boundary="----=_Part_74723_787826626.1729867742479"

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

First, thanks for doing that; this is a nice thing to standardize!

My enthusiasm really comes from the idea that it may be used in several=20
protocols in future (well, and currently), so I'd be keen to see it be=20
sufficiently flexible. Which motivates my reading of it here:

I have a couple of general questions/comments on the design:

Why doesn't the Fiat Shamir challenge (e) include space for a message m?=20
Just like other ZkPoKs that can be really useful, considering that they are=
=20
transferrable.

While it's understandable that you focus on the case of 1 generator being G=
=20
(secp default), it seems like an unnecessary restriction. It's easy to=20
imagine a more complex protocol requiring DLEQs across other pairs of=20
bases. In this case you'd want to include the other base in the Fiat Shamir=
=20
challenge (even if it *is* G). **

I guess no comments on the basic algorithm or the choice of (e,s) vs (R1,=
=20
R2,s) proof encoding (as you've chosen exactly the same as what I chose 8=
=20
years ago for Joinmarket :) ). The handling of k-generation is obviously a=
=20
big step up though.

(**) It's orthogonal to this BIP almost certainly, but it makes me think:=
=20
since we have tons of uses for NUMS generator .. generation in various=20
bitcoin protocols, maybe we should have a BIP just for that? The only=20
reason I suggest that slightly weird idea is, it's explicitly necessary for=
=20
counterparties to be able to reproduce them and it's probably wasteful to=
=20
constantly redefine these other NUMS generators that we're going to use.=20
It's even mentioned in BIP341 for the whole provably unspendable paths=20
thing.

On Wednesday, October 23, 2024 at 8:06:59=E2=80=AFPM UTC-6 Andrew Toth wrot=
e:

> This BIP specifies a standard way to generate and verify DLEQ proofs. Thi=
s=20
> is motivated by sending to silent payments in PSBTs. However, there are=
=20
> also other uses where DLEQs could be useful, so it would be good to have=
=20
> this BIP for others to reference.
>
> This is inspired by=20
> https://github.com/discreetlogcontracts/dlcspecs/blob/master/ECDSA-adapto=
r.md#proof-of-discrete-logarithm-equality,=20
> but is a little more specific.
> There is an implementation of that already at=20
> https://github.com/BlockstreamResearch/secp256k1-zkp/blob/master/src/modu=
les/ecdsa_adaptor/dleq_impl.h,=20
> which this BIP attempts to be compatible with.
>
> Pull request here https://github.com/bitcoin/bips/pull/1689
>
>
> <pre>
>   BIP: ?
>   Title: Discrete Log Equality Proofs over secp256k1
>   Author: Andrew Toth <andre...@gmail.com>
>           Ruben Somsen <rso...@gmail.com>
>   Comments-URI: TBD
>   Status: Draft
>   Type: Standards Track
>   License: BSD-2-Clause
>   Created: 2024-06-29
>   Post-History: TBD
> </pre>
>
> =3D=3D Introduction =3D=3D
>
> =3D=3D=3D Abstract =3D=3D=3D
>
> This document proposes a standard for 64-byte zero-knowledge ''discrete=
=20
> logarithm equality proofs'' (DLEQ proofs) over the elliptic curve=20
> ''secp256k1''. For given elliptic curve points ''A'', ''B'', and ''C'', t=
he=20
> prover proves knowledge of a scalar ''a'' such that ''A =3D a=E2=8B=85G''=
 and ''C =3D=20
> a=E2=8B=85B'' without revealing anything about ''a''. This can, for insta=
nce, be=20
> useful in ECDH: if ''A'' and ''B'' are ECDH public keys, and ''C'' is the=
ir=20
> ECDH shared secret computed as ''C =3D a=E2=8B=85B'', the proof establish=
es that the=20
> same secret key ''a'' is used for generating both ''A'' and ''C'' without=
=20
> revealing ''a''.
>
> =3D=3D=3D Copyright =3D=3D=3D
>
> This document is licensed under the 2-clause BSD license.
>
> =3D=3D=3D Motivation =3D=3D=3D
>
> [
> https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki#specificat=
ion=20
> BIP352] requires senders to compute output scripts using ECDH shared=20
> secrets from the same secret keys used to sign the inputs. Generating an=
=20
> incorrect signature will produce an invalid transaction that will be=20
> rejected by consensus. An incorrectly generated output script can still b=
e=20
> consensus-valid, meaning funds may be lost if it gets broadcast.
> By producing a DLEQ proof for the generated ECDH shared secrets, the=20
> signing entity can prove to other entities that the output scripts have=
=20
> been generated correctly without revealing the private keys.
>
> =3D=3D Specification =3D=3D
>
> All conventions and notations are used as defined in [
> https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki#user-conte=
nt-Notation=20
> BIP327].
>
> =3D=3D=3D DLEQ Proof Generation =3D=3D=3D
>
> Input:
> * The secret key ''a'': a 256-bit unsigned integer
> * The public key ''B'': a point on the curve
> * Auxiliary random data ''r'': a 32-byte array
>
> The algorithm ''Prove(a, B, r)'' is defined as:
> * Fail if ''a =3D 0'' or ''a &ge; n''.
> * Fail if ''is_infinite(B)''.
> * Let ''A =3D a=E2=8B=85G''.
> * Let ''C =3D a=E2=8B=85B''.
> * Let ''t'' be the byte-wise xor of ''bytes(32, a)'' and=20
> ''hash<sub>BIP?/aux</sub>(r)''.
> * Let ''rand =3D hash<sub>DLEQ</sub>(t || cbytes(A) || cytes(C))''.
> * Let ''k =3D int(rand) mod n''.
> * Fail if ''k =3D 0''.
> * Let ''R<sub>1</sub> =3D k=E2=8B=85G''.
> * Let ''R<sub>2</sub> =3D k=E2=8B=85B''.
> * Let ''e =3D int(hash<sub>DLEQ</sub>(cbytes(A) || cbytes(B) || cbytes(C)=
 ||=20
> cbytes(R<sub>1</sub>) || cbytes(R<sub>2</sub>)))''.
> * Let ''proof =3D bytes(32, e) || bytes(32, (k + ea) mod n)''.
> * If ''VerifyProof(A, B, C, proof)'' (see below) returns failure, abort.
> * Return the proof ''proof''.
>
> =3D=3D=3D DLEQ Proof Verification =3D=3D=3D
>
> Input:
> * The public key of the secret key used in the proof generation ''A'': a=
=20
> point on the curve
> * The public key used in the proof generation ''B'': a point on the curve
> * The result of multiplying the secret and public keys used in the proof=
=20
> generation ''C'': a point on the curve
> * A proof ''proof'': a 64-byte array
>
> The algorithm ''VerifyProof(A, B, C, proof)'' is defined as:
> * Let ''e =3D int(proof[0:32])''.
> * Let ''s =3D int(proof[32:64])''; fail if ''s &ge; n''.
> * Let ''R<sub>1</sub> =3D s=E2=8B=85G - e=E2=8B=85A''.
> * Fail if ''is_infinite(R<sub>1</sub>)''.
> * Fail if ''not has_even_y(R<sub>1</sub>)''.
> * Let ''R<sub>2</sub> =3D s=E2=8B=85B - e=E2=8B=85C''.
> * Fail if ''is_infinite(R<sub>2</sub>)''.
> * Fail if ''not has_even_y(R<sub>2</sub>)''.
> * Fail if ''e =E2=89=A0 int(hash<sub>BIP?/DLEQ</sub>(cbytes(A) || cbytes(=
B) ||=20
> cbytes(C) || cbytes(R<sub>1</sub>) || cbytes(R<sub>2</sub>)))''.
> * Return success iff no failure occurred before reaching this point.
>
> =3D=3D Test Vectors and Reference Code =3D=3D
>
> TBD
>
> =3D=3D Changelog =3D=3D
>
> TBD
>
> =3D=3D Footnotes =3D=3D
>
> <references />
>
> =3D=3D Acknowledgements =3D=3D
>
> TBD
>

--=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/=
77ad84ed-2ff8-4929-b8da-d940c95d18a7n%40googlegroups.com.

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

<div>First, thanks for doing that; this is a nice thing to standardize!</di=
v><div><br /></div><div>My enthusiasm really comes from the idea that it ma=
y be used in several protocols in future (well, and currently), so I'd be k=
een to see it be sufficiently flexible. Which motivates my reading of it he=
re:</div><div><br /></div><div>I have a couple of general questions/comment=
s on the design:</div><div><br /></div><div>Why doesn't the Fiat Shamir cha=
llenge (e) include space for a message m? Just like other ZkPoKs that can b=
e really useful, considering that they are transferrable.</div><div><br /><=
/div><div>While it's understandable that you focus on the case of 1 generat=
or being G (secp default), it seems like an unnecessary restriction. It's e=
asy to imagine a more complex protocol requiring DLEQs across other pairs o=
f bases. In this case you'd want to include the other base in the Fiat Sham=
ir challenge (even if it *is* G). **<br /></div><div><br /></div><div>I gue=
ss no comments on the basic algorithm or the choice of (e,s) vs (R1, R2,s) =
proof encoding (as you've chosen exactly the same as what I chose 8 years a=
go for Joinmarket :) ). The handling of k-generation is obviously a big ste=
p up though.</div><div><br /></div><div>(**) It's orthogonal to this BIP al=
most certainly, but it makes me think: since we have tons of uses for NUMS =
generator .. generation in various bitcoin protocols, maybe we should have =
a BIP just for that? The only reason I suggest that slightly weird idea is,=
 it's explicitly necessary for counterparties to be able to reproduce them =
and it's probably wasteful to constantly redefine these other NUMS generato=
rs that we're going to use. It's even mentioned in BIP341 for the whole pro=
vably unspendable paths thing.<br /></div><br /><div class=3D"gmail_quote">=
<div dir=3D"auto" class=3D"gmail_attr">On Wednesday, October 23, 2024 at 8:=
06:59=E2=80=AFPM UTC-6 Andrew Toth wrote:<br/></div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 20=
4, 204); padding-left: 1ex;"><div>
        <div>
 =20
  <span>
    <div>
      <p dir=3D"auto">This BIP specifies a standard way to generate and=20
verify DLEQ proofs. This is motivated by sending to silent payments in=20
PSBTs. However, there are also other uses where DLEQs could be useful,=20
so it would be good to have this BIP for others to reference.</p>
<p dir=3D"auto">This is inspired by <a href=3D"https://github.com/discreetl=
ogcontracts/dlcspecs/blob/master/ECDSA-adaptor.md#proof-of-discrete-logarit=
hm-equality" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"htt=
ps://www.google.com/url?hl=3Den&amp;q=3Dhttps://github.com/discreetlogcontr=
acts/dlcspecs/blob/master/ECDSA-adaptor.md%23proof-of-discrete-logarithm-eq=
uality&amp;source=3Dgmail&amp;ust=3D1729952621492000&amp;usg=3DAOvVaw2XRiw2=
TID36ASfHkZYYMcy">https://github.com/discreetlogcontracts/dlcspecs/blob/mas=
ter/ECDSA-adaptor.md#proof-of-discrete-logarithm-equality</a>, but is a lit=
tle more specific.<br>
There is an implementation of that already at <a href=3D"https://github.com=
/BlockstreamResearch/secp256k1-zkp/blob/master/src/modules/ecdsa_adaptor/dl=
eq_impl.h" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https=
://www.google.com/url?hl=3Den&amp;q=3Dhttps://github.com/BlockstreamResearc=
h/secp256k1-zkp/blob/master/src/modules/ecdsa_adaptor/dleq_impl.h&amp;sourc=
e=3Dgmail&amp;ust=3D1729952621492000&amp;usg=3DAOvVaw2iWQZevsllLYMFrGlHX2-_=
">https://github.com/BlockstreamResearch/secp256k1-zkp/blob/master/src/modu=
les/ecdsa_adaptor/dleq_impl.h</a>, which this BIP attempts to be compatible=
 with.</p><p dir=3D"auto">Pull request here <a href=3D"https://github.com/b=
itcoin/bips/pull/1689" target=3D"_blank" rel=3D"nofollow" data-saferedirect=
url=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://github.com/bitcoi=
n/bips/pull/1689&amp;source=3Dgmail&amp;ust=3D1729952621492000&amp;usg=3DAO=
vVaw21rGZjPuj6J-YdQkgNmiKl">https://github.com/bitcoin/bips/pull/1689</a></=
p><p dir=3D"auto"><br></p>&lt;pre&gt;<br>=C2=A0 BIP: ?<br>=C2=A0 Title: Dis=
crete Log Equality Proofs over secp256k1<br>=C2=A0 Author: Andrew Toth &lt;=
<a href data-email-masked rel=3D"nofollow">andre...@gmail.com</a>&gt;<br>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ruben Somsen &lt;<a href data-email-mask=
ed rel=3D"nofollow">rso...@gmail.com</a>&gt;<br>=C2=A0 Comments-URI: TBD<br=
>=C2=A0 Status: Draft<br>=C2=A0 Type: Standards Track<br>=C2=A0 License: BS=
D-2-Clause<br>=C2=A0 Created: 2024-06-29<br>=C2=A0 Post-History: TBD<br>&lt=
;/pre&gt;<br><br>=3D=3D Introduction =3D=3D<br><br>=3D=3D=3D Abstract =3D=
=3D=3D<br><br>This document proposes a standard for 64-byte zero-knowledge =
&#39;&#39;discrete logarithm equality proofs&#39;&#39; (DLEQ proofs) over t=
he elliptic curve &#39;&#39;secp256k1&#39;&#39;. For given elliptic curve p=
oints &#39;&#39;A&#39;&#39;, &#39;&#39;B&#39;&#39;, and &#39;&#39;C&#39;&#3=
9;, the prover proves knowledge of a scalar &#39;&#39;a&#39;&#39; such that=
 &#39;&#39;A =3D a=E2=8B=85G&#39;&#39; and &#39;&#39;C =3D a=E2=8B=85B&#39;=
&#39; without revealing anything about &#39;&#39;a&#39;&#39;. This can, for=
 instance, be useful in ECDH: if &#39;&#39;A&#39;&#39; and &#39;&#39;B&#39;=
&#39; are ECDH public keys, and &#39;&#39;C&#39;&#39; is their ECDH shared =
secret computed as &#39;&#39;C =3D a=E2=8B=85B&#39;&#39;, the proof establi=
shes that the same secret key &#39;&#39;a&#39;&#39; is used for generating =
both &#39;&#39;A&#39;&#39; and &#39;&#39;C&#39;&#39; without revealing &#39=
;&#39;a&#39;&#39;.<br><br>=3D=3D=3D Copyright =3D=3D=3D<br><br>This documen=
t is licensed under the 2-clause BSD license.<br><br>=3D=3D=3D Motivation =
=3D=3D=3D<br><br>[<a href=3D"https://github.com/bitcoin/bips/blob/master/bi=
p-0352.mediawiki#specification" target=3D"_blank" rel=3D"nofollow" data-saf=
eredirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://github.c=
om/bitcoin/bips/blob/master/bip-0352.mediawiki%23specification&amp;source=
=3Dgmail&amp;ust=3D1729952621493000&amp;usg=3DAOvVaw0qHBZpprb3hsSkjcaYE6lb"=
>https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki#specificati=
on</a> BIP352] requires senders to compute output scripts using ECDH shared=
 secrets from the same secret keys used to sign the inputs. Generating an i=
ncorrect signature will produce an invalid transaction that will be rejecte=
d by consensus. An incorrectly generated output script can still be consens=
us-valid, meaning funds may be lost if it gets broadcast.<br>By producing a=
 DLEQ proof for the generated ECDH shared secrets, the signing entity can p=
rove to other entities that the output scripts have been generated correctl=
y without revealing the private keys.<br><br>=3D=3D Specification =3D=3D<br=
><br>All conventions and notations are used as defined in [<a href=3D"https=
://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki#user-content-Nota=
tion" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://ww=
w.google.com/url?hl=3Den&amp;q=3Dhttps://github.com/bitcoin/bips/blob/maste=
r/bip-0327.mediawiki%23user-content-Notation&amp;source=3Dgmail&amp;ust=3D1=
729952621493000&amp;usg=3DAOvVaw1LTAW7cdWLumiTdy12ajIH">https://github.com/=
bitcoin/bips/blob/master/bip-0327.mediawiki#user-content-Notation</a> BIP32=
7].<br><br>=3D=3D=3D DLEQ Proof Generation =3D=3D=3D<br><br>Input:<br>* The=
 secret key &#39;&#39;a&#39;&#39;: a 256-bit unsigned integer<br>* The publ=
ic key &#39;&#39;B&#39;&#39;: a point on the curve<br>* Auxiliary random da=
ta &#39;&#39;r&#39;&#39;: a 32-byte array<br><br>The algorithm &#39;&#39;Pr=
ove(a, B, r)&#39;&#39; is defined as:<br>* Fail if &#39;&#39;a =3D 0&#39;&#=
39; or &#39;&#39;a &amp;ge; n&#39;&#39;.<br>* Fail if &#39;&#39;is_infinite=
(B)&#39;&#39;.<br>* Let &#39;&#39;A =3D a=E2=8B=85G&#39;&#39;.<br>* Let &#3=
9;&#39;C =3D a=E2=8B=85B&#39;&#39;.<br>* Let &#39;&#39;t&#39;&#39; be the b=
yte-wise xor of &#39;&#39;bytes(32, a)&#39;&#39; and &#39;&#39;hash&lt;sub&=
gt;BIP?/aux&lt;/sub&gt;(r)&#39;&#39;.<br>* Let &#39;&#39;rand =3D hash&lt;s=
ub&gt;DLEQ&lt;/sub&gt;(t || cbytes(A) || cytes(C))&#39;&#39;.<br>* Let &#39=
;&#39;k =3D int(rand) mod n&#39;&#39;.<br>* Fail if &#39;&#39;k =3D 0&#39;&=
#39;.<br>* Let &#39;&#39;R&lt;sub&gt;1&lt;/sub&gt; =3D k=E2=8B=85G&#39;&#39=
;.<br>* Let &#39;&#39;R&lt;sub&gt;2&lt;/sub&gt; =3D k=E2=8B=85B&#39;&#39;.<=
br>* Let &#39;&#39;e =3D int(hash&lt;sub&gt;DLEQ&lt;/sub&gt;(cbytes(A) || c=
bytes(B) || cbytes(C) || cbytes(R&lt;sub&gt;1&lt;/sub&gt;) || cbytes(R&lt;s=
ub&gt;2&lt;/sub&gt;)))&#39;&#39;.<br>* Let &#39;&#39;proof =3D bytes(32, e)=
 || bytes(32, (k + ea) mod n)&#39;&#39;.<br>* If &#39;&#39;VerifyProof(A, B=
, C, proof)&#39;&#39; (see below) returns failure, abort.<br>* Return the p=
roof &#39;&#39;proof&#39;&#39;.<br><br>=3D=3D=3D DLEQ Proof Verification =
=3D=3D=3D<br><br>Input:<br>* The public key of the secret key used in the p=
roof generation &#39;&#39;A&#39;&#39;: a point on the curve<br>* The public=
 key used in the proof generation &#39;&#39;B&#39;&#39;: a point on the cur=
ve<br>* The result of multiplying the secret and public keys used in the pr=
oof generation &#39;&#39;C&#39;&#39;: a point on the curve<br>* A proof &#3=
9;&#39;proof&#39;&#39;: a 64-byte array<br><br>The algorithm &#39;&#39;Veri=
fyProof(A, B, C, proof)&#39;&#39; is defined as:<br>* Let &#39;&#39;e =3D i=
nt(proof[0:32])&#39;&#39;.<br>* Let &#39;&#39;s =3D int(proof[32:64])&#39;&=
#39;; fail if &#39;&#39;s &amp;ge; n&#39;&#39;.<br>* Let &#39;&#39;R&lt;sub=
&gt;1&lt;/sub&gt; =3D s=E2=8B=85G - e=E2=8B=85A&#39;&#39;.<br>* Fail if &#3=
9;&#39;is_infinite(R&lt;sub&gt;1&lt;/sub&gt;)&#39;&#39;.<br>* Fail if &#39;=
&#39;not has_even_y(R&lt;sub&gt;1&lt;/sub&gt;)&#39;&#39;.<br>* Let &#39;&#3=
9;R&lt;sub&gt;2&lt;/sub&gt; =3D s=E2=8B=85B - e=E2=8B=85C&#39;&#39;.<br>* F=
ail if &#39;&#39;is_infinite(R&lt;sub&gt;2&lt;/sub&gt;)&#39;&#39;.<br>* Fai=
l if &#39;&#39;not has_even_y(R&lt;sub&gt;2&lt;/sub&gt;)&#39;&#39;.<br>* Fa=
il if &#39;&#39;e =E2=89=A0 int(hash&lt;sub&gt;BIP?/DLEQ&lt;/sub&gt;(cbytes=
(A) || cbytes(B) || cbytes(C) || cbytes(R&lt;sub&gt;1&lt;/sub&gt;) || cbyte=
s(R&lt;sub&gt;2&lt;/sub&gt;)))&#39;&#39;.<br>* Return success iff no failur=
e occurred before reaching this point.<br><br>=3D=3D Test Vectors and Refer=
ence Code =3D=3D<br><br>TBD<br><br>=3D=3D Changelog =3D=3D<br><br>TBD<br><b=
r>=3D=3D Footnotes =3D=3D<br><br>&lt;references /&gt;<br><br>=3D=3D Acknowl=
edgements =3D=3D<br><br>TBD</div>
  </span>
 =20
</div>

      </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/77ad84ed-2ff8-4929-b8da-d940c95d18a7n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/77ad84ed-2ff8-4929-b8da-d940c95d18a7n%40googlegroups.com</a>.<br />

------=_Part_74723_787826626.1729867742479--

------=_Part_74722_461499448.1729867742479--