Author: Federico Tenga 2017-07-27 16:52:52
Published on: 2017-07-27T16:52:52+00:00
Bitcoin developers have proposed a standard for timelocked funds that is shared and common among multiple implementations of Bitcoin wallets. The proposal allows users to voluntarily impose a lock time during which a majority of their funds cannot be spent, as well as create timelocked addresses redeemable at some set date on each month, providing the private redemption codes to the beneficiary. By having a single standard for timelocked funds, users can be assured that the redemption code for the funds will still be usable even if the software or service no longer exists after several years.The proposal outlines formats for specifying an address that locks funds until a specified date and a redemption code that allows the funds to be swept on or after the specified date. The human-readable part of both addresses is composed of the four characters 'hodl', followed by a date in YYYYMMDD form, and a network code of either tb for testnet or bc for Bitcoin mainnet. The lock time computed for a particular YYYYMMDD date uses the day before the lock date and the time 1000h of the date from the above step. To make timelocking backwards compatible with wallets that do not support this BIP, a simple service can translate from a public timelocked address to a P2SH address. The proposal recommends that wallets supporting payment to P2PKH, P2SH, P2WPKH, and P2WSH Bitcoin addresses should reuse the same interface for paying into timelocked addresses of this proposal. The public address format uses "hodl" as the start of the code, while the private key (the redemption code) uses "hedl". This provides a simple mnemonic for users: "Pay into the hodl code to hold your coins until the given date. After you've held the coins (on or after the given date) use the hedl code to redeem the coins." The obvious misspelling of "hodl" is a homage to the common meme within the Bitcoin community. Additionally, a version quintet is added in case of future sociopolitical events that changes interpretation of dates, or changes in scripting that would allow for more efficient redemptions of timelocked funds. Such changes are unlikely, so the version is a quintet in the bech32 data part rather than a substring in the human-readable part.
Updated on: 2023-06-12T03:27:56.482883+00:00