<pre>BIP: ?Title: Standard address format for timelocked fundsAuthor: ZmnSCPxj <***@protonmail.com>Comments-Summary: ?Comments-URI: ?Status: ?Type: ?Created: 2017-07-01License: CC0-1.0</pre>== Abstract ==<code>OP_CHECKLOCKTIMEVERIFY</code> provides a method oflocking funds until a particular time arrives.One potential use of this opcode is for a user to precommithimself or herself to not spend funds until a particulardate, i.e. to hold the funds until a later date.This proposal adds a format for specifying addresses thatprecommit to timelocked funds, as well as specifying aredemption code to redeem funds after the timelock haspassed.This allows ordinary non-technical users to make use of<code>OP_CHECKLOCKTIMEVERIFY</code> easily.== Copyright ==This BIP is released under CC0-1.0.== Specification ==This proposal provides formats for specifying anaddress that locks funds until a specified date,and a redemption code that allows the funds to beswept on or after the specified date.At minimum, wallet software supporting this BIP mustbe capable of sweeping the redemption code on or afterthe specified date.In addition, the wallet software should support sendingfunds to the timelocked address specified here.Finally, wallet software may provide a command to createa pair of timelocked address and redemption code.Addresses and redemption codes are encoded using[https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#Bech32Bech32 encoding].=== Timelocked Address Format ===The human-readable part of the address is composed of:# The four characters <code>hodl</code>.# A date, in <code>YYYYMMDD</code> form. For example,the date August 1, 2017 is encoded as <code>20170801</code>.# A network code, either <code>tb</code> for testnet,or <code>bc</code> for Bitcoin mainnet.The data part of the address is composed of:# A version quintet (5 bits), which must be 0 for thisBIP.# A public key hash, 32 quintets (160 bits). As isusual for Bitcoin, this is big-endian.This is to be interpreted as follows:# The given date is the first day that the funds inthe given address may be redeemed.# The funds are owned by whoever controls the privatekey corresponding to the public key hash given.=== Redemption Code ===The human-readable part of the redemption code iscomposed of:# The four characters <code>hedl</code>.# A date, in <code>YYYYMMDD</code> form.# A network code, either <code>tb</code> for testnet,or <code>bc</code> for Bitcoin mainnet.The data part of the address is composed of:# A version quintet (5 bits), which must be 0 for thisBIP.# A private key, 52 quintets (260 bits). This is the256-bit private key, prepended with 4 <code>0</code>bits, in big-endian order. <!-- We could considersome kind of mini private key instead if the securityis similar anyway. -->This is to be interpreted as follows:# The given date is the first day that the funds inthe given address may be redeemed.# The private key unlocks the funds.=== Lock Time Computation ===Given a particular lock date <code>YYYYMMDD</code>, theactual lock time is computed as follows:# The day before the lock date is taken. For example,if the lock date is <code>20180101</code> orJanuary 1, 2018, we take the date December 31, 2017.# We take the time 1000h (10:00 AM, or 10 in the morning)of the date from the above step.This lock time is then translated to aUnix epoch time, as per POSIX.1-2001 (which removes thebuggy day February 29, 2100 in previous POSIX revisions).The translation should use, at minimum, unsigned 32-bitnumbers to represent the Unix epoch time.The Unix epoch time shall then be interpreted as an<code>nLockTime</code> value, as per standard Bitcoin.Whether it is possible to represent dates past 2038will depend on whether standard Bitcoin can represent<code>nLockTime</code> values to represent dates past2038.Since <code>nLockTime</code> is an unsigned 32-bitvalue, it should be possible to represent dates until06:28:15 UTC+0 2106-02-07.Future versions of Bitcoin should be able to support<code>nLockTime</code> larger than unsigned 32-bit,in order to allow even later dates.The reason for using an earlier lock time than thespecified date is given in the Rationale section ofthis BIP.=== Payment to a Timelocked Address ===An ordinary P2SH payment is used to provide funds to atimelocked address.The script below is used as the <code>redeemScript</code>for the P2SH payment:<timeout> OP_CHECKLOCKTIMEVERIFY OP_DROPOP_DUP OP_HASH160 <publickeyhash> OP_EQUALVERIFY OP_CHECKSIGOnce the <code>redeemScript</code> is derived, the hash isdetermined, and an ordinary P2SH output with the below<code>scriptPubKey</code> used:OP_HASH160 <redeemScripthash> OP_EQUALIn case of SegWit deployment, SegWit-compatible walletsshould be able to use P2SH, P2WSH, or P2SH-P2WSH, as perthe output they would normally use in that situation.Obviously, a timelocked address has an equivalentBitcoin <code>3</code> (P2SH) address.A simple service or software that translates from apublic timelocked address to a P2SH address can becreated that makes timelocking (but not redemption)backwards compatible with wallets that do not supportthis BIP.This proposal recommends that wallets supporting paymentto P2PKH, P2SH, P2WPKH, and P2WSH Bitcoin addresses shouldreuse the same interface for paying to such addresses aspaying into timelocked addresses of this proposal.=== Redemption of a Timelocked Redemption Code ===To sweep a timelocked redemption code after the timelock,one must provide the given <code>redeemScript</code> aspart of the <code>scriptSig</code>, of all unspentoutputs that pay to the given <code>redeemScript</code>hash.When sweeping a timelocked redemption code, first thewallet must extract the private key from the redemptioncode, then derive the public key, the public key hash,the <code>redeemScript</code>, and finally the<code>redeemScript</code> hash.Then, the wallet must find all unspent outputs that payto the <code>redeemScript</code> hash via P2SH (and, in thecase of SegWit deployment, via P2SH-P2WSH and P2WSH).For each such output, the wallet then generates atransaction input with the below <code>scriptSig</code>, asper usual P2SH redemptions:<signature> <pubkey> <redeemScript>The wallet then outputs to an address it can control.As the Script involved uses <code>OP_CHECKLOCKTIMEVERIFY</code>,the <code>nSequence</code> must be 0 and the<code>nLockTime</code> must be equal to the computedlock time.This implies that the transaction cannot be transmitted(and the funds cannot be sweeped)until after the given lock time.The above procedure is roughly identical to sweeping anordinary, exported private key.This proposal recommends that wallets supporting a sweepfunction should reuse the same interface for sweepingindividual private keys (wallet import format) for sweepingtimelocked redemption codes.== Motivation ==A key motivation for this BIP is to allow easy use of<code>OP_CHECKLOCKTIMEVERIFY</code> by end-users.The below are expected use cases of this proposal:# A user wants to purchase an amount of Bitcoin,and subsequently wait for an amount of time beforecashing out.The user fears that he or she may have "weak hands",i.e. sell unfavorably on a temporary dip, and thuscommits the coins into a timelocked fund that canonly be opened after a specific date.# A user wants to gift an amount of Bitcoins toan infant or minor, and wants the fund to not be spenton ill-advised purchases until the infant or minorreaches the age of maturity.# A user may wish to prepare some kind of monthly subsidyor allowance to another user, and prepares a series oftimelocked addresses, redeemable at some set date oneach month, and provides the private redemption codes tothe beneficiary.# A user may fear duress or ransom for a particularfuture time horizon, and voluntarily impose a lock timeduring which a majority of their funds cannot be spent.== Rationale ==While in principle, this proposal may be implemented as aseparate service or software, we should consider the longtime horizons that may be desired by users.A user using a particular software to timelock a fund mayhave concerns, for example, of specifying a timelock18 years in the future for a gift or inheritance to anewborn infant.The software or service may no longer exist after 18 years,unless the user himself or herself takes over maintenanceof that software or service.By having a single standard for timelocked funds that isshared and common among multiple implementations of Bitcoinwallets, the user has some assurance that the redemption codefor the funds is still useable after 18 years.Further, a publicly-accessible standard specifying how thefunds can be redeemed will allow technically-capable usersor beneficiaries to create software that can redeem thetimelocked fund.This proposal provides a timelock at the granularity of aday.The expectation is that users will have long timedurations of months or years, so that the ability tospecify exact times, which would require specifying thetimezone, is unneeded.The actual timeout used is 1000h of the day before thehuman-readable date, so that timezones of UTC+14 willdefinitely be able to redeem the money starting at0000h of the human-readable date, local time (UTC+14).Given the expectation that users will use long timedurations, the fact that timezones of UTC-12 willactually be able to redeem the funds on 2200h UTC-12time two days before can be considered an acceptableerror.The human-readable date is formatted according to[https://www.iso.org/iso-8601-date-and-time-format.htmlISO standard dates], with the dashes removed.Dashes may prevent double-click selection, makingusability of these addresses less desirable.<!--We can consider something like 2021m12d11 instead,which would be much more readable and understandableto human users.-->The <code>bc</code> or <code>tb</code> is after thedate since the date is composed of digits and the bech32separator itself is the digit <code>1</code>. Onesimply needs to compare <code>hedlbc202111211...</code>and <code>hedl20211121bc1...</code>.A version quintet is added in case of a futuresociopolitical event that changes interpretation ofdates, or changes in scripting that would allow for moreefficient redemptions of timelocked funds (which wouldchange the <code>redeemScript</code> paid to), or changesin the size and/or format of lock times, and so on.Such changes are unlikely, so the version is a quintet inthe bech32 data part rather than a substring in thehuman-readable part.The public address format uses the <code>hodl</code> asthe start of the code, while the private key (theredemption code) uses <code>hedl</code>.This provides a simple mnemonic for users:"Pay into the <code>hodl</code> code to hold yourcoins until the given date.After you've held the coins (on or after the given date)use the <code>hedl</code> code to redeem the coins."The obvious misspelling of "hodl" is a homage to the commonmeme within the Bitcoin community.<!-- The above misspelling may be corrected if it is consideredto be in bad taste. -->

Good morning mailinglist,I am saddened at the lack of attention to this BIP proposal. I know that it is not as interesting as the debates on where Bitcoin will go in the future and what needs to be prepared for even greater mainstream adoption, but I think my BIP proposal does have at least some value to long-term investors.So far I have seen only a single public feedback:https://www.reddit.com/r/Bitcoin/comments/6lzpvz/bip_hodl/djxzbvi/Basically, the point in that feedback is mostly that the computed timelock should be UTC+0 0000h of the given human-readable date.I would like to respectfully ask the mailing list about which option is best:1. (current) Use the earliest timezone as of now, UTC+14 0000h of the given human-readable date. Pro: No matter where you are in the world, as soon as the given date arrives, the fund can be spent. Con: For most of the world, the fund can be spent on some time the day before, or even two days before for UTC-11 and UTC-12 timezones.2. Use the standard timezone UTC+0 0000h of the given human-readable date. Pro: standard time. Con: for half of the world, the fund is not spendable until some time into the given date, for the other half, it will be spendable at an earlier date.3. Allow indicating a timezone to the human-readable part. Pro: gives control over the user's expected local time. Con: additional field and effectively more control, need to handle also strange timezones that have 0.5 hour difference from UTC, need to encode positive and negative preferably without using + and -, as those may break double-click selection.I hope to get some feedback from this list.Regards,ZmnSCPxj-------- Original Message --------Subject: [bitcoin-dev] [BIP Proposal] Standard address format for timelocked fundsLocal Time: July 8, 2017 9:13 AMUTC Time: July 8, 2017 1:13 AMFrom: bitcoin-***@lists.linuxfoundation.orgTo: bitcoin-dev <bitcoin-***@lists.linuxfoundation.org><pre>BIP: ?Title: Standard address format for timelocked fundsAuthor: ZmnSCPxj <***@protonmail.com>Comments-Summary: ?Comments-URI: ?Status: ?Type: ?Created: 2017-07-01License: CC0-1.0</pre>== Abstract ==<code>OP_CHECKLOCKTIMEVERIFY</code> provides a method oflocking funds until a particular time arrives.One potential use of this opcode is for a user to precommithimself or herself to not spend funds until a particulardate, i.e. to hold the funds until a later date.This proposal adds a format for specifying addresses thatprecommit to timelocked funds, as well as specifying aredemption code to redeem funds after the timelock haspassed.This allows ordinary non-technical users to make use of<code>OP_CHECKLOCKTIMEVERIFY</code> easily.== Copyright ==This BIP is released under CC0-1.0.== Specification ==This proposal provides formats for specifying anaddress that locks funds until a specified date,and a redemption code that allows the funds to beswept on or after the specified date.At minimum, wallet software supporting this BIP mustbe capable of sweeping the redemption code on or afterthe specified date.In addition, the wallet software should support sendingfunds to the timelocked address specified here.Finally, wallet software may provide a command to createa pair of timelocked address and redemption code.Addresses and redemption codes are encoded using[https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#Bech32Bech32 encoding].=== Timelocked Address Format ===The human-readable part of the address is composed of:# The four characters <code>hodl</code>.# A date, in <code>YYYYMMDD</code> form. For example,the date August 1, 2017 is encoded as <code>20170801</code>.# A network code, either <code>tb</code> for testnet,or <code>bc</code> for Bitcoin mainnet.The data part of the address is composed of:# A version quintet (5 bits), which must be 0 for thisBIP.# A public key hash, 32 quintets (160 bits). As isusual for Bitcoin, this is big-endian.This is to be interpreted as follows:# The given date is the first day that the funds inthe given address may be redeemed.# The funds are owned by whoever controls the privatekey corresponding to the public key hash given.=== Redemption Code ===The human-readable part of the redemption code iscomposed of:# The four characters <code>hedl</code>.# A date, in <code>YYYYMMDD</code> form.# A network code, either <code>tb</code> for testnet,or <code>bc</code> for Bitcoin mainnet.The data part of the address is composed of:# A version quintet (5 bits), which must be 0 for thisBIP.# A private key, 52 quintets (260 bits). This is the256-bit private key, prepended with 4 <code>0</code>bits, in big-endian order. <!-- We could considersome kind of mini private key instead if the securityis similar anyway. -->This is to be interpreted as follows:# The given date is the first day that the funds inthe given address may be redeemed.# The private key unlocks the funds.=== Lock Time Computation ===Given a particular lock date <code>YYYYMMDD</code>, theactual lock time is computed as follows:# The day before the lock date is taken. For example,if the lock date is <code>20180101</code> orJanuary 1, 2018, we take the date December 31, 2017.# We take the time 1000h (10:00 AM, or 10 in the morning)of the date from the above step.This lock time is then translated to aUnix epoch time, as per POSIX.1-2001 (which removes thebuggy day February 29, 2100 in previous POSIX revisions).The translation should use, at minimum, unsigned 32-bitnumbers to represent the Unix epoch time.The Unix epoch time shall then be interpreted as an<code>nLockTime</code> value, as per standard Bitcoin.Whether it is possible to represent dates past 2038will depend on whether standard Bitcoin can represent<code>nLockTime</code> values to represent dates past2038.Since <code>nLockTime</code> is an unsigned 32-bitvalue, it should be possible to represent dates until06:28:15 UTC+0 2106-02-07.Future versions of Bitcoin should be able to support<code>nLockTime</code> larger than unsigned 32-bit,in order to allow even later dates.The reason for using an earlier lock time than thespecified date is given in the Rationale section ofthis BIP.=== Payment to a Timelocked Address ===An ordinary P2SH payment is used to provide funds to atimelocked address.The script below is used as the <code>redeemScript</code>for the P2SH payment:<timeout> OP_CHECKLOCKTIMEVERIFY OP_DROPOP_DUP OP_HASH160 <publickeyhash> OP_EQUALVERIFY OP_CHECKSIGOnce the <code>redeemScript</code> is derived, the hash isdetermined, and an ordinary P2SH output with the below<code>scriptPubKey</code> used:OP_HASH160 <redeemScripthash> OP_EQUALIn case of SegWit deployment, SegWit-compatible walletsshould be able to use P2SH, P2WSH, or P2SH-P2WSH, as perthe output they would normally use in that situation.Obviously, a timelocked address has an equivalentBitcoin <code>3</code> (P2SH) address.A simple service or software that translates from apublic timelocked address to a P2SH address can becreated that makes timelocking (but not redemption)backwards compatible with wallets that do not supportthis BIP.This proposal recommends that wallets supporting paymentto P2PKH, P2SH, P2WPKH, and P2WSH Bitcoin addresses shouldreuse the same interface for paying to such addresses aspaying into timelocked addresses of this proposal.=== Redemption of a Timelocked Redemption Code ===To sweep a timelocked redemption code after the timelock,one must provide the given <code>redeemScript</code> aspart of the <code>scriptSig</code>, of all unspentoutputs that pay to the given <code>redeemScript</code>hash.When sweeping a timelocked redemption code, first thewallet must extract the private key from the redemptioncode, then derive the public key, the public key hash,the <code>redeemScript</code>, and finally the<code>redeemScript</code> hash.Then, the wallet must find all unspent outputs that payto the <code>redeemScript</code> hash via P2SH (and, in thecase of SegWit deployment, via P2SH-P2WSH and P2WSH).For each such output, the wallet then generates atransaction input with the below <code>scriptSig</code>, asper usual P2SH redemptions:<signature> <pubkey> <redeemScript>The wallet then outputs to an address it can control.As the Script involved uses <code>OP_CHECKLOCKTIMEVERIFY</code>,the <code>nSequence</code> must be 0 and the<code>nLockTime</code> must be equal to the computedlock time.This implies that the transaction cannot be transmitted(and the funds cannot be sweeped)until after the given lock time.The above procedure is roughly identical to sweeping anordinary, exported private key.This proposal recommends that wallets supporting a sweepfunction should reuse the same interface for sweepingindividual private keys (wallet import format) for sweepingtimelocked redemption codes.== Motivation ==A key motivation for this BIP is to allow easy use of<code>OP_CHECKLOCKTIMEVERIFY</code> by end-users.The below are expected use cases of this proposal:# A user wants to purchase an amount of Bitcoin,and subsequently wait for an amount of time beforecashing out.The user fears that he or she may have "weak hands",i.e. sell unfavorably on a temporary dip, and thuscommits the coins into a timelocked fund that canonly be opened after a specific date.# A user wants to gift an amount of Bitcoins toan infant or minor, and wants the fund to not be spenton ill-advised purchases until the infant or minorreaches the age of maturity.# A user may wish to prepare some kind of monthly subsidyor allowance to another user, and prepares a series oftimelocked addresses, redeemable at some set date oneach month, and provides the private redemption codes tothe beneficiary.# A user may fear duress or ransom for a particularfuture time horizon, and voluntarily impose a lock timeduring which a majority of their funds cannot be spent.== Rationale ==While in principle, this proposal may be implemented as aseparate service or software, we should consider the longtime horizons that may be desired by users.A user using a particular software to timelock a fund mayhave concerns, for example, of specifying a timelock18 years in the future for a gift or inheritance to anewborn infant.The software or service may no longer exist after 18 years,unless the user himself or herself takes over maintenanceof that software or service.By having a single standard for timelocked funds that isshared and common among multiple implementations of Bitcoinwallets, the user has some assurance that the redemption codefor the funds is still useable after 18 years.Further, a publicly-accessible standard specifying how thefunds can be redeemed will allow technically-capable usersor beneficiaries to create software that can redeem thetimelocked fund.This proposal provides a timelock at the granularity of aday.The expectation is that users will have long timedurations of months or years, so that the ability tospecify exact times, which would require specifying thetimezone, is unneeded.The actual timeout used is 1000h of the day before thehuman-readable date, so that timezones of UTC+14 willdefinitely be able to redeem the money starting at0000h of the human-readable date, local time (UTC+14).Given the expectation that users will use long timedurations, the fact that timezones of UTC-12 willactually be able to redeem the funds on 2200h UTC-12time two days before can be considered an acceptableerror.The human-readable date is formatted according to[https://www.iso.org/iso-8601-date-and-time-format.htmlISO standard dates], with the dashes removed.Dashes may prevent double-click selection, makingusability of these addresses less desirable.<!--We can consider something like 2021m12d11 instead,which would be much more readable and understandableto human users.-->The <code>bc</code> or <code>tb</code> is after thedate since the date is composed of digits and the bech32separator itself is the digit <code>1</code>. Onesimply needs to compare <code>hedlbc202111211...</code>and <code>hedl20211121bc1...</code>.A version quintet is added in case of a futuresociopolitical event that changes interpretation ofdates, or changes in scripting that would allow for moreefficient redemptions of timelocked funds (which wouldchange the <code>redeemScript</code> paid to), or changesin the size and/or format of lock times, and so on.Such changes are unlikely, so the version is a quintet inthe bech32 data part rather than a substring in thehuman-readable part.The public address format uses the <code>hodl</code> asthe start of the code, while the private key (theredemption code) uses <code>hedl</code>.This provides a simple mnemonic for users:"Pay into the <code>hodl</code> code to hold yourcoins until the given date.After you've held the coins (on or after the given date)use the <code>hedl</code> code to redeem the coins."The obvious misspelling of "hodl" is a homage to the commonmeme within the Bitcoin community.<!-- The above misspelling may be corrected if it is consideredto be in bad taste. -->