Re: [bitcoin-dev] [BIP Proposal] Standard address format for timelocked funds

[Federico Tenga via bitcoin-dev]

Hi ZmnSCPxj,

Few thoughts about your proposal:
1- I kinda like the idea and I would probably use it, but still I believe
it is a very limited use case and probably most wallet providers will not
be interested in supporting it.
2- Early adopters and people highly involved in the community may
appreciate the "hodl" part in the redemption code, but it could cause
confusion in normal users not understanding the reference.

Regarding the time-zone I think the best option is to stick the UTC
standard, using UTC+14 could be confusing since it is very unusual  and we
are not used to deal with it.



On 12 July 2017 at 10:30, ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 h 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 h 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 h 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 funds
> Local Time: July 8, 2017 9:13 AM
> UTC Time: July 8, 2017 1:13 AM
> From: bitcoin-dev@lists.linuxfoundation.org
> To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
>
>
> 
> BIP: ?
> Title: Standard address format for timelocked funds
> Author: ZmnSCPxj <zmnsc...@protonmail.com>
> Comments-Summary: ?
> Comments-URI: ?
> Status: ?
> Type: ?
> Created: 2017-07-01
> License: CC0-1.0
> 
>
> == Abstract ==
>
> OP_CHECKLOCKTIMEVERIFY provides a method of
> locking funds until a particular time arrives.
> One potential use of this opcode is for a user to precommit
> himself or herself to not spend funds until a particular
> date, i.e. to hold the funds until a later date.
>
> This proposal adds a format for specifying addresses that
> precommit to timelocked funds, as well as specifying a
> redemption code to redeem funds after the timelock has
> passed.
> This allows ordinary non-technical users to make use of
> OP_CHECKLOCKTIMEVERIFY easily.
>
> == Copyright ==
>
> This BIP is released under CC0-1.0.
>
> == Specification ==
>
> This proposal provides 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.
>
> At minimum, wallet software supporting this BIP must
> be capable of sweeping the redemption code on or after
> the specified date.
> In addition, the wallet software should support sending
> funds to the timelocked address specified here.
> Finally, wallet software may provide a command to create
> a pair of timelocked address and redemption code.
>
> Addresses and redemption codes are encoded using
> [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#Bech32
> Bech32 encoding].
>
> === Timelocked Address Format ===
>
> The human-readable part of the address is composed of:
>
> # The four characters hodl.
> # A date, in MMDD form.  For example,
>   the date August 1, 2017 is encoded as 20170801.
> # A network code, either tb for testnet,
>   or bc for Bitcoin mainnet.
>
> The data part of the ad

Re: [bitcoin-dev] [BIP Proposal] Standard address format for timelocked funds

[ZmnSCPxj via bitcoin-dev]

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 h 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 h 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 h 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 
funds
Local Time: July 8, 2017 9:13 AM
UTC Time: July 8, 2017 1:13 AM
From: bitcoin-dev@lists.linuxfoundation.org
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>

BIP: ?
Title: Standard address format for timelocked funds
Author: ZmnSCPxj <zmnsc...@protonmail.com>
Comments-Summary: ?
Comments-URI: ?
Status: ?
Type: ?
Created: 2017-07-01
License: CC0-1.0

== Abstract ==
OP_CHECKLOCKTIMEVERIFY provides a method of
locking funds until a particular time arrives.
One potential use of this opcode is for a user to precommit
himself or herself to not spend funds until a particular
date, i.e. to hold the funds until a later date.
This proposal adds a format for specifying addresses that
precommit to timelocked funds, as well as specifying a
redemption code to redeem funds after the timelock has
passed.
This allows ordinary non-technical users to make use of
OP_CHECKLOCKTIMEVERIFY easily.
== Copyright ==
This BIP is released under CC0-1.0.
== Specification ==
This proposal provides 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.
At minimum, wallet software supporting this BIP must
be capable of sweeping the redemption code on or after
the specified date.
In addition, the wallet software should support sending
funds to the timelocked address specified here.
Finally, wallet software may provide a command to create
a pair of timelocked address and redemption code.
Addresses and redemption codes are encoded using
[https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#Bech32
Bech32 encoding].
=== Timelocked Address Format ===
The human-readable part of the address is composed of:
# The four characters hodl.
# A date, in MMDD form. For example,
the date August 1, 2017 is encoded as 20170801.
# A network code, either tb for testnet,
or bc for Bitcoin mainnet.
The data part of the address is composed of:
# A version quintet (5 bits), which must be 0 for this
BIP.
# A public key hash, 32 quintets (160 bits). As is
usual for Bitcoin, this is big-endian.
This is to be interpreted as follows:
# The given date is the first day that the funds in
the given address may be redeemed.
# The funds are owned by whoever controls the private
key corresponding to the public key hash given.
=== Redemption Code ===
The human-readable part of the redemption code is
composed of:
# The four characters hedl.
# A date, in MMDD form.
# A network code, either tb for testnet,
or bc for Bitcoin mainnet.
The data part of the address is composed of:
# A version quintet (5 bits), which must be 0 for this
BIP.
# A private key, 52 quintets (260 bits). This is the
256-bit private key, prepended with 4 0
bits, in big-endian order. 
This is to be interpreted as follows:
# The given date is the first day that the funds in
the given address may be redeemed.
# The private key unlocks the funds.
=== Lock Time Computation ===
Given a particular lock date MMDD, the
actual lock time is computed as follows:
# The day before the lock date is taken. For example,
if the lock date is 20180101 or
January 1, 2018, we take the date December 31, 2017.
# We take the time 

[bitcoin-dev] [BIP Proposal] Standard address format for timelocked funds

[ZmnSCPxj via bitcoin-dev]

BIP: ?
Title: Standard address format for timelocked funds
Author: ZmnSCPxj 
Comments-Summary: ?
Comments-URI: ?
Status: ?
Type: ?
Created: 2017-07-01
License: CC0-1.0

== Abstract ==
OP_CHECKLOCKTIMEVERIFY provides a method of
locking funds until a particular time arrives.
One potential use of this opcode is for a user to precommit
himself or herself to not spend funds until a particular
date, i.e. to hold the funds until a later date.
This proposal adds a format for specifying addresses that
precommit to timelocked funds, as well as specifying a
redemption code to redeem funds after the timelock has
passed.
This allows ordinary non-technical users to make use of
OP_CHECKLOCKTIMEVERIFY easily.
== Copyright ==
This BIP is released under CC0-1.0.
== Specification ==
This proposal provides 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.
At minimum, wallet software supporting this BIP must
be capable of sweeping the redemption code on or after
the specified date.
In addition, the wallet software should support sending
funds to the timelocked address specified here.
Finally, wallet software may provide a command to create
a pair of timelocked address and redemption code.
Addresses and redemption codes are encoded using
[https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#Bech32
Bech32 encoding].
=== Timelocked Address Format ===
The human-readable part of the address is composed of:
# The four characters hodl.
# A date, in MMDD form. For example,
the date August 1, 2017 is encoded as 20170801.
# A network code, either tb for testnet,
or bc for Bitcoin mainnet.
The data part of the address is composed of:
# A version quintet (5 bits), which must be 0 for this
BIP.
# A public key hash, 32 quintets (160 bits). As is
usual for Bitcoin, this is big-endian.
This is to be interpreted as follows:
# The given date is the first day that the funds in
the given address may be redeemed.
# The funds are owned by whoever controls the private
key corresponding to the public key hash given.
=== Redemption Code ===
The human-readable part of the redemption code is
composed of:
# The four characters hedl.
# A date, in MMDD form.
# A network code, either tb for testnet,
or bc for Bitcoin mainnet.
The data part of the address is composed of:
# A version quintet (5 bits), which must be 0 for this
BIP.
# A private key, 52 quintets (260 bits). This is the
256-bit private key, prepended with 4 0
bits, in big-endian order. 
This is to be interpreted as follows:
# The given date is the first day that the funds in
the given address may be redeemed.
# The private key unlocks the funds.
=== Lock Time Computation ===
Given a particular lock date MMDD, the
actual lock time is computed as follows:
# The day before the lock date is taken. For example,
if the lock date is 20180101 or
January 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 a
Unix epoch time, as per POSIX.1-2001 (which removes the
buggy day February 29, 2100 in previous POSIX revisions).
The translation should use, at minimum, unsigned 32-bit
numbers to represent the Unix epoch time.
The Unix epoch time shall then be interpreted as an
nLockTime value, as per standard Bitcoin.
Whether it is possible to represent dates past 2038
will depend on whether standard Bitcoin can represent
nLockTime values to represent dates past
2038.
Since nLockTime is an unsigned 32-bit
value, it should be possible to represent dates until
06:28:15 UTC+0 2106-02-07.
Future versions of Bitcoin should be able to support
nLockTime larger than unsigned 32-bit,
in order to allow even later dates.
The reason for using an earlier lock time than the
specified date is given in the Rationale section of
this BIP.
=== Payment to a Timelocked Address ===
An ordinary P2SH payment is used to provide funds to a
timelocked address.
The script below is used as the redeemScript
for the P2SH payment:
 OP_CHECKLOCKTIMEVERIFY OP_DROP
OP_DUP OP_HASH160  OP_EQUALVERIFY OP_CHECKSIG
Once the redeemScript is derived, the hash is
determined, and an ordinary P2SH output with the below
scriptPubKey used:
OP_HASH160  OP_EQUAL
In case of SegWit deployment, SegWit-compatible wallets
should be able to use P2SH, P2WSH, or P2SH-P2WSH, as per
the output they would normally use in that situation.
Obviously, a timelocked address has an equivalent
Bitcoin 3 (P2SH) address.
A simple service or software that translates from a
public timelocked address to a P2SH address can be
created that makes timelocking (but not redemption)
backwards compatible with wallets that do not support
this BIP.
This proposal recommends that wallets supporting payment
to P2PKH, P2SH, P2WPKH, and P2WSH Bitcoin addresses should
reuse the same interface for paying to such addresses as