From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 01 Jan 2026 08:22:48 -0800 Received: from mail-ot1-f61.google.com ([209.85.210.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vbLRn-000539-49 for bitcoindev@gnusha.org; Thu, 01 Jan 2026 08:22:48 -0800 Received: by mail-ot1-f61.google.com with SMTP id 46e09a7af769-7c72ccd60f5sf27755437a34.0 for ; Thu, 01 Jan 2026 08:22:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1767284561; x=1767889361; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to: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=arfHWxgOD4g1TF5GirikaBHI6vZ8/OBJwKTx+ZJK1lY=; b=LXjub7M97rW166M/t/xH3ohrp0v1DOEgf21aVyPiOcRjJHgnrzMjzaZTKl7GXRJM2/ YNmpewyP20dXskWPDOuYVPhG1SWleW5AWBIN3R0U4iAXkvf++ETjF38nxV3mkXwgfLob +9ygvJoDzoEh8PmZsbtg9TUg2UEIG3ld6UaUXPjlu+9Z7j9bX3Zcr51jD0Ij3pPCP2br Z8uwTeTuYS2uaXnQZ2mzDpTvoE4zoO/qWbCYUh78Qu0sPUb+xFAE7IpQmsVtowcNN79m 34c82EJQXQGFxRwAZKSNl3hrXuOaG8lZ2maZs6Zi7XgfOnibuh4kwoTXvZ5ZnRy6+5xl 17Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767284561; x=1767889361; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:references:in-reply-to:message-id:to:from:date :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=arfHWxgOD4g1TF5GirikaBHI6vZ8/OBJwKTx+ZJK1lY=; b=rP++n83KNG8fKuAs3Kzw0T/dy3g1WJQox51fuaaGLZlmm0rGN/nky7ldLQdkh/BCgW oCJ43aWtS959V1dHKs68Uvgxbn28MyIqwkboeJ3e0n4uw+i5axAfzxixJI2rrVCVSqiA 59m2CHcEJ0z2moZy90iVSVvJgtZtid4x/05o8luzj7Ijh5dVIEHkvEmqD94bcVnKPKx5 6c7raovrBgaXjh6BB6rxomArsRf8R1y4BFhJPhL0o6ceURvNHTMZBxYzvYCRS4gJUck5 K3hsZ0Mh5v+PIHcDR2uzdo7VqYXcdOwQH8FDEZ0EQWB9KPdtByALF0aNagjkuOrg8e2o cQnw== X-Forwarded-Encrypted: i=1; AJvYcCVupee59NxrfDmA8Da2N5Mb4jQngNuyjtIqPzCOZ3NYS1GMJp1hUI7eEhaywsE1hG80L9ov5sDBvAhH@gnusha.org X-Gm-Message-State: AOJu0YzfVERgVE4zPO+eDBhIIP1/3nhrdgEbGA3MnvtkEKKoCXzeR7HR TcrfmWEAHS617GetURg+uuzMW83+QnKYCZ5UWsQf33+T6j2jDeaW0U1h X-Google-Smtp-Source: AGHT+IFVbA/jkymNaRlPCP9Ks1cN6KBbbJkn0k4r+VBBI7/aU4qMmDkJsn/x3OvWrIePPXubdQdXNQ== X-Received: by 2002:a4a:e9ec:0:b0:659:9a49:9071 with SMTP id 006d021491bc7-65d0eac94a8mr11820576eaf.60.1767284560707; Thu, 01 Jan 2026 08:22:40 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWbdpmvj/p0xcx0ZPILnFNk+FE/f0zCPzNZMA4GjmPguIg==" Received: by 2002:a05:6820:7404:b0:65c:f62a:5ab1 with SMTP id 006d021491bc7-65cf62a60c1ls6099542eaf.1.-pod-prod-05-us; Thu, 01 Jan 2026 08:22:36 -0800 (PST) X-Received: by 2002:a05:6808:3507:b0:44f:6d70:45af with SMTP id 5614622812f47-457b20eb7eamr16441713b6e.9.1767284556773; Thu, 01 Jan 2026 08:22:36 -0800 (PST) Received: by 2002:a05:690c:4a92:b0:786:6c46:840 with SMTP id 00721157ae682-78fb39c9e68ms7b3; Thu, 1 Jan 2026 08:18:44 -0800 (PST) X-Received: by 2002:a05:690e:bcc:b0:644:71f7:a9ee with SMTP id 956f58d0204a3-6466a8ec1fdmr26509468d50.97.1767284322268; Thu, 01 Jan 2026 08:18:42 -0800 (PST) Date: Thu, 1 Jan 2026 08:18:41 -0800 (PST) From: "'Oren' via Bitcoin Development Mailing List" To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: <8fefdd9e-8c71-4e11-9d90-ebbd8e25dc56n@googlegroups.com> Subject: [bitcoindev] Re: BIP idea: Timelock-Recovery storage format MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1583108_323822359.1767284321852" X-Original-Sender: orenz0@protonmail.com X-Original-From: Oren Reply-To: Oren 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.7 (/) ------=_Part_1583108_323822359.1767284321852 Content-Type: multipart/alternative; boundary="----=_Part_1583109_274484624.1767284321852" ------=_Part_1583109_274484624.1767284321852 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi AdamSZ, list, Thanks for showing interest in the BIP and happy new year. > Btw, do you think you should address directly the philosophy found in=20 Liana, and what setups they have decided to expose? (i.e. what's the delta,= =20 here). Yes, I think it's a good idea to talk about the advantages and=20 disadvantages of pre-signed transactions vs script-based wallets. I'll add= =20 it to the Motivation section. > Should the BIP actually be something with more flexibility in transaction= =20 structure, so as to cover more use-cases? I think it's good to limit the structure of the transactions, so that=20 different services could easily integrate this feature. One guy that I talked to suggested building a more sophisticated sequence= =20 of transactions with multiple wallets, for example that after 90 days the= =20 Bitcoin will move to his wife's wallet, from which there will be another=20 pre-signed transaction that moves the Bitcoin to his brother's wallet after= =20 180 days, etc. But after all, trying to support all custom logics and use-cases will end= =20 up in a service that compiles general-purpose "code" instead of something= =20 useful for standard users. > Is there a case for requesting a feature in Core that one could do a=20 'testmempoolaccept' with a conditional setting of the time/block height as= =20 argument? I've asked for a testmempoolaccept RPC that ignores nSequence/nLocktime=20 here: https://github.com/bitcoin/bitcoin/issues/32142=20 It's a problem even in transactions with a single nLocktime.=20 testmempoolaccept breaks on the first problem that it finds. Suppose you=20 are signing a transaction with a future nLocktime, and testmempoolaccept=20 breaks on "non-final" - how do you know that there are no other problems in= =20 the transaction? How can you tell that the cryptographic signatures are=20 good, and what if it's a script-based wallet? Some worry that complicate the testmempoolaccept RPC diverge from how=20 transactions are checked in sendrawtransaction, and I somewhat agree with= =20 that. Checking the signatures of P2WPKH wallets is straight-forward, but in order= =20 to build a service that verifies the Recovery transaction of a complicated= =20 wallet (i.e. multisig, taproot, etc.), without initiating the plan - I=20 guess you would need to run a node with patched code for testmempoolaccept. > I'm probably being an idiot, but: since you're defining alert_inputs as= =20 just txid:vout, what's the point of including it since that data is already= =20 in alert_tx, no? I did mention that the JSON has some information duplicated. Even the=20 alert_txid can be calculated from the raw transaction. This is useful for displaying the information to the user for review. For= =20 example, a webpage to which you drag-n-drop the JSON file, shows you its=20 information and has a button saying "Upload for Monitoring". This will allow the frontend to show the user the list of UTXOs covered by= =20 the recovery-plan, without complicated frontend-code to parse the raw=20 transaction. Of course, if the user clicks "Upload for Monitoring" and the backend finds= =20 out that the alert_inputs mismatch the raw transaction, the whole process= =20 should be rejected with a warning that the file was corrupt (possibly=20 maliciously). > One last thing, that 388 day limit is a little unfortunate, no? I=20 certainly think a year is a good, reasonable "long time", but still, all=20 the same. 388 days is just the maximal value that you get from BIP-68: After setting the correct bit flags, the relative-locktime is calculated=20 from the lowest 16 bits, in units of 512 seconds. This gives a maximal value of (2^16 - 1) * 512 seconds =3D 33,553,920 secon= ds=20 =3D 388 days, 8 hours and 32 minutes. Users can obviously choose a shorter cancellation-window. Regards, Oren On Thursday, January 1, 2026 at 4:34:07=E2=80=AFPM UTC+2 waxwing/ AdamISZ w= rote: > Hi Oren, list, > > I do think this is a really good general idea - and certainly fits into= =20 > "this could be a BIP". Current covenant-less "deadman's switch" style=20 > systems are of course limited, but useful, at least to the enthusiast tha= t=20 > can hand-craft them. Avoiding the "need to refresh every interval" is=20 > clearly desirable, though the extra complexity *may* end up being more=20 > trouble than it's worth (clearly, you don't think so!). > > Btw, do you think you should address directly the philosophy found in=20 > Liana, and what setups they have decided to expose? (i.e. what's the delt= a,=20 > here). > Should the BIP actually be something with more flexibility in transaction= =20 > structure, so as to cover more use-cases? > > Other comments stimulated by the BIP text: > > "The testmempoolaccept RPC can receive a list of transactions in which th= e=20 > later transactions may depend on earlier transactions - however in our ca= se=20 > the Recovery Transaction has an nSequence relative-locktime, and therefor= e=20 > calling testmempoolaccept 'alert-tx' 'recovery-tx' will fail, claiming th= at=20 > the Alert Transaction UTXO is not confirmed (and the required time window= =20 > has not passed). " > > This sounds like a pretty chunky and important problem (which surprised= =20 > me, as in, it never occurred to me). Speaking for myself, I would not res= t=20 > easy with a recovery plan that I couldn't unambiguously check as follows:= =20 > "I really, really want to know that this recovery works, but much more th= an=20 > that, I *must* know that it doesn't work (leak my funds) before the=20 > intended deadline". > > With a single nlocktime you can do that (testmempoolaccept -> "non-final"= ). > > Is there a case for requesting a feature in Core that one could do a=20 > 'testmempoolaccept' with a conditional setting of the time/block height a= s=20 > argument? Would that solve this issue? I'm guessing not, as (clue is in t= he=20 > name!) the tool was mostly designed around "how does this tx interact wit= h=20 > the currently seen mempool" more than "forget conflicts, is this even=20 > valid/could it ever be valid in and of itself?" (yeah perhaps it's just a= n=20 > incoherent question..?). > > "alert_inputs (mandatory): An array of up to 10,000 inputs spent by the= =20 > Alert Transaction. Each input is a string in the format "txid:vout" where= =20 > txid is a 64-character lowercase hexadecimal string and vout is a decimal= =20 > number of up to 6 digits. > alert_tx (mandatory): The raw Alert Transaction in uppercase hexadecimal= =20 > format. A string of up to 800,000 characters." > > I'm probably being an idiot, but: since you're defining alert_inputs as= =20 > just txid:vout, what's the point of including it since that data is alrea= dy=20 > in alert_tx, no? > > One last thing, that 388 day limit is a little unfortunate, no? I=20 > certainly think a year is a good, reasonable "long time", but still, all= =20 > the same. > > Cheers, > AdamISZ/waxwing > > On Sunday, December 28, 2025 at 11:59:43=E2=80=AFAM UTC-3 Oren wrote: > >> Reposting here from BitcoinTalk=20 >> : >> >> After a short talk with Ava Chow during BTC++ Taiwan, I'm starting this= =20 >> thread to discuss whether my idea is BIP-worthy. >> >> Motivation for Timelock-Recovery plans: >> Storing seeds for recovery & inheritance is scary. >> Pre-signed transactions to a secondary-wallet/custodian, are safer to=20 >> handle and backup due to their immutability. >> A single pre-signed transaction with a future nLocktime requires=20 >> "renewal" when the nLocktime deadline is getting close, which could be= =20 >> annoying (i.e. if the seed is split over multiple geographic locations). >> Covenants/Vaults are still being debated, and could scare less-technical= =20 >> Bitcoiners. >> >> Solution: >> Pre-signing a pair of transactions: >> =E2=80=A2 Alert/Initiate Transaction: A consolidation transaction that k= eeps=20 >> most funds on the original wallet (except for a minimal amount that goes= to=20 >> anchor-addresses, for CPFP acceleration) >> =E2=80=A2 Recovery Transaction: A transaction that moves the Bitcoin fro= m the=20 >> consolidated UTXO to the secondary-wallet(s), with an nSequence=20 >> relative-locktime that gives the user enough time to move the funds=20 >> elsewhere (assuming they noticed that the Alert transaction was mined, a= nd=20 >> still have the seed or signed an alternative transaction in advance). >> >> Similar to a single pre-signed transaction with a future nLocktime,=20 >> Timelock-Recovery plans will not include new funds that are added to the= =20 >> wallet, and will be revoked even if a tiny amount is spent. This mechani= sm=20 >> is intended for wallets that are going to remain untouched for a long ti= me. >> >> An example implementation can be found in the Timelock Recovery plugin= =20 >> that I've implemented for Electrum (merged since= =20 >> Electrum v4.6.0b1). Details and demo videos can be found at:=20 >> https://timelockrecovery.com. >> The plugin creates a UI for signing the two transactions, then saving=20 >> them either in a PDF file (with detailed manual instructions for=20 >> less-technological Bitcoiners how to broadcast them), or in a *JSON=20 >> format*. >> >> The BIP will be about the JSON format, which includes not only the raw= =20 >> transactions themselves, but also user-information (i.e. name, descripti= on,=20 >> destination-labels, wallet-name, wallet-version), and data about the=20 >> transactions (i.e. txids, amounts, fees, input-utxos, anchor-addresses,= =20 >> relative-locktime). >> A standard JSON format will allow implementing a compatible feature on= =20 >> other wallets, as well as apps/servers for monitoring & initiating=20 >> timelock-recovery plans - such as the one being developed by RITREK.com= =20 >> (disclosure: I'm one of RITREK's founders). >> >> Let me know what you think! >> >> Oren >> >> --=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/= a4295d52-8553-42d6-82d6-5605476d3c38n%40googlegroups.com. ------=_Part_1583109_274484624.1767284321852 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi AdamSZ, list,
Thanks for showing interest in the BIP and happy new = year.

> Btw, do you think you should address directly the phi= losophy found in Liana, and what setups they have decided to expose? (i.e. = what's the delta, here).
Yes, I think it's a good idea to talk about t= he advantages and disadvantages of pre-signed transactions vs script-based = wallets. I'll add it to the Motivation section.

> Should the = BIP actually be something with more flexibility in transaction structure, s= o as to cover more use-cases?
I think it's good to limit the structure= of the transactions, so that different services could easily integrate thi= s feature.
One guy that I talked to suggested building a more sophisti= cated sequence of transactions with multiple wallets, for example that afte= r 90 days the Bitcoin will move to his wife's wallet, from which there will= be another pre-signed transaction that moves the Bitcoin to his brother's = wallet after 180 days, etc.
But after all, trying to support all custo= m logics and use-cases will end up in a service that compiles general-purpo= se "code" instead of something useful for standard users.

> I= s there a case for requesting a feature in Core that one could do a 'testme= mpoolaccept' with a conditional setting of the time/block height as argumen= t?
I've asked for a testmempoolaccept RPC that ignores nSequence/nLocktime here: https://github.com/bitcoin/bit= coin/issues/32142
It's a problem even in transactions with a single n= Locktime. testmempoolaccept breaks on the= first problem that it finds. Suppose you are signing a transaction with a = future nLocktime, and testmempoolaccept b= reaks on "non-final" - how do you know that there are no other problems in = the transaction? How can you tell that the cryptographic signatures are goo= d, and what if it's a script-based wallet?
Some worry that complicate = the testmempoolaccept RPC diverge from how transactions are checked in sendrawtransaction, and I somewhat agree with= that.
Checking the signatures of P2WPKH wallets is straight-forward, = but in order to build a service that verifies the Recovery transaction of a= complicated wallet (i.e. multisig, taproot, etc.), without initiating the = plan - I guess you would need to run a node with patched code for testmempoolaccept.

> I'm probably be= ing an idiot, but: since you're defining alert_inputs as just txid:vout, wh= at's the point of including it since that data is already in alert_tx, no?<= br />I did mention that the JSON has some information duplicated. Even the = alert_txid can be calculated from the raw transaction.
This is useful = for displaying the information to the user for review. For example, a webpa= ge to which you drag-n-drop the JSON file, shows you its information and ha= s a button saying "Upload for Monitoring".
This will allow the fronten= d to show the user the list of UTXOs covered by the recovery-plan, without = complicated frontend-code to parse the raw transaction.
Of course, if = the user clicks "Upload for Monitoring" and the backend finds out that the = alert_inputs mismatch the raw transaction, the whole process should be reje= cted with a warning that the file was corrupt (possibly maliciously).
=
> One last thing, that 388 day limit is a little unfortunate, no? = I certainly think a year is a good, reasonable "long time", but still, all = the same.
388 days is just the maximal value that you get from BIP-68:=
After setting the correct bit flags, the relative-locktime is calcula= ted from the lowest 16 bits, in units of 512 seconds.
This gives a max= imal value of (2^16 - 1) * 512 seconds =3D 33,553,920 seconds =3D 388 days,= 8 hours and 32 minutes.
Users can obviously choose a shorter cancella= tion-window.

Regards,
Oren

=
On Thursd= ay, January 1, 2026 at 4:34:07=E2=80=AFPM UTC+2 waxwing/ AdamISZ wrote:
Hi Oren, li= st,

I do think this is a really good general idea = - and certainly fits into "this could be a BIP". Current covenant= -less "deadman's switch" style systems are of course limited,= but useful, at least to the enthusiast that can hand-craft them. Avoiding = the "need to refresh every interval" is clearly desirable, though= the extra complexity *may* end up being more trouble than it's worth (= clearly, you don't think so!).

Btw, do you think you should addr= ess directly the philosophy found in Liana, and what setups they have decid= ed to expose? (i.e. what's the delta, here).
Should the BIP a= ctually be something with more flexibility in transaction structure, so as = to cover more use-cases?

Other comments stimulated by the BIP text:<= /div>

"The testmempoolaccept RPC can receive a list of transac= tions in which the later transactions may depend on earlier transactions - = however in our case the Recovery Transaction has an nSequence relative-lock= time, and therefore calling testmempoolaccept 'alert-tx' 'recov= ery-tx' will fail, claiming that the Alert Transaction UTXO is not conf= irmed (and the required time window has not passed). "

This sou= nds like a pretty chunky and important problem (which surprised me, as in, = it never occurred to me). Speaking for myself, I would not rest easy with a= recovery plan that I couldn't unambiguously check as follows: "I = really, really want to know that this recovery works, but much more than th= at, I *must* know that it doesn't work (leak my funds) before the inten= ded deadline".

With a single nlocktime you can do that (testmem= poolaccept -> "non-final").

Is there a case for request= ing a feature in Core that one could do a 'testmempoolaccept' with = a conditional setting of the time/block height as argument? Would that solv= e this issue? I'm guessing not, as (clue is in the name!) the tool was = mostly designed around "how does this tx interact with the currently s= een mempool" more than "forget conflicts, is this even valid/coul= d it ever be valid in and of itself?" (yeah perhaps it's just an i= ncoherent question..?).

"alert_inputs (mandatory): An array of = up to 10,000 inputs spent by the Alert Transaction. Each input is a string = in the format "txid:vout" where txid is a 64-character lowercase = hexadecimal string and vout is a decimal number of up to 6 digits.
alert= _tx (mandatory): The raw Alert Transaction in uppercase hexadecimal format.= A string of up to 800,000 characters."

I'm probably being = an idiot, but: since you're defining alert_inputs as just txid:vout, wh= at's the point of including it since that data is already in alert_tx, = no?

One last thing, that 388 day limit is a little unfort= unate, no? I certainly think a year is a good, reasonable "long time&q= uot;, but still, all the same.

Cheers,
A= damISZ/waxwing

On Sunday, December 28, 2025 at 11:59:43=E2=80=AFAM UTC-3 O= ren wrote:
Reposting h= ere from BitcoinTalk:

After a short talk with= Ava Chow during BTC++ Taiwan, I'm starting this thread to discuss whet= her my idea is BIP-worthy.

Motivation for Timelock-Recovery plans:Storing seeds for recovery & inheritance is scary.
Pre-signed tran= sactions to a secondary-wallet/custodian, are safer to handle and backup du= e to their immutability.
A single pre-signed transaction with a future <= font face=3D"Courier New">nLocktime requires "renewal" whe= n the nLocktime deadline is getting close= , which could be annoying (i.e. if the seed is split over multiple geograph= ic locations).
Covenants/Vaults are still being debated, and could scare= less-technical Bitcoiners.

Solution:
Pre-signing a pair of trans= actions:
=E2=80=A2 Alert/Initiate Transaction: A consolidation trans= action that keeps most funds on the original wallet (except for a minimal a= mount that goes to anchor-addresses, for CPFP acceleration)
=E2=80=A2 Recovery Transaction: A transaction that moves the Bitcoin from the cons= olidated UTXO to the secondary-wallet(s), with an nLocktime, Timelock-Recovery plans will not i= nclude new funds that are added to the wallet, and will be revoked even if = a tiny amount is spent. This mechanism is intended for wallets that are goi= ng to remain untouched for a long time.

An example implementation ca= n be found in the Timelock Recovery plugin that I've implemented for Electrum (merged since Electrum v4.6.0b1). Details an= d demo videos can be found at: https://= timelockrecovery.com.
The plugin creates a UI for signing the two tr= ansactions, then saving them either in a PDF file (with detailed manual ins= tructions for less-technological Bitcoiners how to broadcast them), or in a= JSON format.

The BIP will be about the JSON format, which in= cludes not only the raw transactions themselves, but also user-information = (i.e. name, description, destination-labels, wallet-name, wallet-version), = and data about the transactions (i.e. txids, amounts, fees, input-utxos, an= chor-addresses, relative-locktime).
A standard JSON format will allow im= plementing a compatible feature on other wallets, as well as apps/servers f= or monitoring & initiating timelock-recovery plans - such as the one be= ing developed by RITREK.com (disclosure: I'm one of= RITREK's founders).

Let me know what you think!

Oren
=

--
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 visit https://groups.google.com/d/msgid/bitcoind= ev/a4295d52-8553-42d6-82d6-5605476d3c38n%40googlegroups.com.
------=_Part_1583109_274484624.1767284321852-- ------=_Part_1583108_323822359.1767284321852--