summaryrefslogtreecommitdiff
path: root/cd/757bc6c90ade8d7aff1526f06297f872f045d3
blob: 5933fe8859e493bc6fa04f0b6d35d199bc2772cd (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
Return-Path: <federicotenga@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 5187EAE0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 27 Jul 2017 16:52:56 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f181.google.com (mail-io0-f181.google.com
	[209.85.223.181])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3C9FC133
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 27 Jul 2017 16:52:54 +0000 (UTC)
Received: by mail-io0-f181.google.com with SMTP id m88so72648691iod.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 27 Jul 2017 09:52:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=AdF8fm0w3FjNtPR4n/E/s/3t+YAvwKzr/kIRgUEGgGs=;
	b=MnjMNbBsdyhEtpzpruGI29IqI3S9VRpO93FM7AtrDTHZP2F0o1tGrmkdav2jN0LITo
	IKyCGa8Srxc0rhL602S9GWjCQz0Zn9DMLm9rlfb0pdGu1hJlLAIgLF0D7+tgbNIszoy8
	YT38WDWaM3e+V706A0lcXxtCOtVodMPtJl1Tg070DNWT5w6uXP+KlaESF9KeoV09D2T9
	+WHE+99XB6fxk5drnRyGKxxUORWgbsoR2rpmWghTFOQCQ2j4bolGBQjgjZhUYunebl/X
	swt76fDculakRhPcqzEkLWL0DzGI3KYeMxA9ljJYcm5aGZ1ERrXHTKKPLt1gPnfGGbdX
	yMxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=AdF8fm0w3FjNtPR4n/E/s/3t+YAvwKzr/kIRgUEGgGs=;
	b=q8PJgYMvPZK85bkgAagcz5FVPuUtxgbXpq8tKoGVgphb2xqHMKCIlGOQltPHsV4zC1
	7UaAZp2K4TW/OAe2v5HhtRAykaXlGCI/UEroXlHMJSjRABbc5ITnNi/KCOyRw5PsGAXx
	1Vby8R+dohe4uTtVTCx8t0jJjjOLjxvE9SYFh3oNPaxjBX1LX1KpfcAFoOqUnly3Ip4Y
	rxLLM9j7c+nC7NXEE6dWSGRbLD2iRSaEgDt5iyJPeZehmaYDTbs6IIulFcw8HnY3l4k2
	ISpuYAr+pO+Mzg9QABEoWIO4EZ8bSbQ+2chljCDxwursTPQBrIcw3su/LUL0kjZHpCI9
	0tAQ==
X-Gm-Message-State: AIVw111LSay8tT2Eot3NMRch+ZpZMV5oaDAjZu9iuGDan+Jfq8IlKg9s
	Uo1VP5cgeFpQIY/5W/59Zxtle7xFOw==
X-Received: by 10.107.179.135 with SMTP id c129mr5921564iof.106.1501174373449; 
	Thu, 27 Jul 2017 09:52:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.10.130 with HTTP; Thu, 27 Jul 2017 09:52:52 -0700 (PDT)
In-Reply-To: <ST-p1uYWpwTa6RLgXAd5NLgZwt_rzJdxQaK2X5kp6gmjmj-uCw8VNANcfR3mAMBFV5D4j52TC6fX612pFWkrcg2jpjiDtLnGHyd6DQtt7Oo=@protonmail.com>
References: <VxtMcRFeh3Yr86KleeyK3BeZ9_KJVSmRtMgIdanwcEe23IrBwK0Q_ozC_EyxX6KHRcpePKgnaBk9KsY_i77k4Be3QEosXhUwbj561t4oJqw=@protonmail.com>
	<ST-p1uYWpwTa6RLgXAd5NLgZwt_rzJdxQaK2X5kp6gmjmj-uCw8VNANcfR3mAMBFV5D4j52TC6fX612pFWkrcg2jpjiDtLnGHyd6DQtt7Oo=@protonmail.com>
From: Federico Tenga <federicotenga@gmail.com>
Date: Thu, 27 Jul 2017 18:52:52 +0200
Message-ID: <CAP=-fx6xGHa=1BO6xKfjQ5pfWnRECtps+RQQp2oXYyZu5XjPxA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a114853be46855305554f6590"
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE, 
	RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 27 Jul 2017 17:34:37 +0000
Subject: Re: [bitcoin-dev] [BIP Proposal] Standard address format for
 timelocked funds
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jul 2017 16:52:56 -0000

--001a114853be46855305554f6590
Content-Type: text/plain; charset="UTF-8"

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 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 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>
>
>
> <pre>
> BIP: ?
> Title: Standard address format for timelocked funds
> Author: ZmnSCPxj <ZmnSCPxj@protonmail.com>
> Comments-Summary: ?
> Comments-URI: ?
> Status: ?
> Type: ?
> Created: 2017-07-01
> License: CC0-1.0
> </pre>
>
> == Abstract ==
>
> <code>OP_CHECKLOCKTIMEVERIFY</code> 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
> <code>OP_CHECKLOCKTIMEVERIFY</code> 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 <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 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 <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 this
>   BIP.
> # A private key, 52 quintets (260 bits).  This is the
>   256-bit private key, prepended with 4 <code>0</code>
>   bits, in big-endian order.   <!-- We could consider
>   some kind of mini private key instead if the security
>   is similar anyway.  -->
>
> 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 <code>YYYYMMDD</code>, the
> actual lock time is computed as follows:
>
> # The day before the lock date is taken.  For example,
>   if the lock date is <code>20180101</code> 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
> <code>nLockTime</code> value, as per standard Bitcoin.
> Whether it is possible to represent dates past 2038
> will depend on whether standard Bitcoin can represent
> <code>nLockTime</code> values to represent dates past
> 2038.
> Since <code>nLockTime</code> 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
> <code>nLockTime</code> 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 <code>redeemScript</code>
> for the P2SH payment:
>
> <timeout> OP_CHECKLOCKTIMEVERIFY OP_DROP
> OP_DUP OP_HASH160 <publickeyhash> OP_EQUALVERIFY OP_CHECKSIG
>
> Once the <code>redeemScript</code> is derived, the hash is
> determined, and an ordinary P2SH output with the below
> <code>scriptPubKey</code> used:
>
> OP_HASH160 <redeemScripthash> 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 <code>3</code> (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
> paying 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> as
> part of the <code>scriptSig</code>, of all unspent
> outputs that pay to the given <code>redeemScript</code>
> hash.
>
> When sweeping a timelocked redemption code, first the
> wallet must extract the private key from the redemption
> code, 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 pay
> to the <code>redeemScript</code> hash via P2SH (and, in the
> case of SegWit deployment, via P2SH-P2WSH and P2WSH).
>
> For each such output, the wallet then generates a
> transaction input with the below <code>scriptSig</code>, as
> per 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 computed
> lock 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 an
> ordinary, exported private key.
>
> This proposal recommends that wallets supporting a sweep
> function should reuse the same interface for sweeping
> individual private keys (wallet import format) for sweeping
> timelocked 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 before
> cashing out.
> The user fears that he or she may have "weak hands",
> i.e. sell unfavorably on a temporary dip, and thus
> commits the coins into a timelocked fund that can
> only be opened after a specific date.
> # A user wants to gift an amount of Bitcoins to
> an infant or minor, and wants the fund to not be spent
> on ill-advised purchases until the infant or minor
> reaches the age of maturity.
> # A user may wish to prepare some kind of monthly subsidy
> or allowance to another user, and prepares a series of
> timelocked addresses, redeemable at some set date on
> each month, and provides the private redemption codes to
> the beneficiary.
> # A user may fear duress or ransom for a particular
> future time horizon, and voluntarily impose a lock time
> during which a majority of their funds cannot be spent.
>
> == Rationale ==
>
> While in principle, this proposal may be implemented as a
> separate service or software, we should consider the long
> time horizons that may be desired by users.
> A user using a particular software to timelock a fund may
> have concerns, for example, of specifying a timelock
> 18 years in the future for a gift or inheritance to a
> newborn infant.
> The software or service may no longer exist after 18 years,
> unless the user himself or herself takes over maintenance
> of that software or service.
> By having a single standard for timelocked funds that is
> shared and common among multiple implementations of Bitcoin
> wallets, the user has some assurance that the redemption code
> for the funds is still useable after 18 years.
> Further, a publicly-accessible standard specifying how the
> funds can be redeemed will allow technically-capable users
> or beneficiaries to create software that can redeem the
> timelocked fund.
>
> This proposal provides a timelock at the granularity of a
> day.
> The expectation is that users will have long time
> durations of months or years, so that the ability to
> specify exact times, which would require specifying the
> timezone, is unneeded.
>
> The actual timeout used is 1000h of the day before the
> human-readable date, so that timezones of UTC+14 will
> definitely be able to redeem the money starting at
> 0000h of the human-readable date, local time (UTC+14).
> Given the expectation that users will use long time
> durations, the fact that timezones of UTC-12 will
> actually be able to redeem the funds on 2200h UTC-12
> time two days before can be considered an acceptable
> error.
>
> The human-readable date is formatted according to
> [https://www.iso.org/iso-8601-date-and-time-format.html
> ISO standard dates], with the dashes removed.
> Dashes may prevent double-click selection, making
> usability of these addresses less desirable.
> <!--
> We can consider something like 2021m12d11 instead,
> which would be much more readable and understandable
> to human users.
> -->
>
> The <code>bc</code> or <code>tb</code> is after the
> date since the date is composed of digits and the bech32
> separator itself is the digit <code>1</code>.  One
> simply needs to compare <code>hedlbc202111211...</code>
> and <code>hedl20211121bc1...</code>.
>
> A version quintet is added in case of a future
> sociopolitical event that changes interpretation of
> dates, or changes in scripting that would allow for more
> efficient redemptions of timelocked funds (which would
> change the <code>redeemScript</code> paid to), or changes
> in the size and/or format of lock times, and so on.
> Such changes are unlikely, so the version is a quintet in
> the bech32 data part rather than a substring in the
> human-readable part.
>
> The public address format uses the <code>hodl</code> as
> the start of the code, while the private key (the
> redemption code) uses <code>hedl</code>.
> This provides a simple mnemonic for users:
> "Pay into the <code>hodl</code> code to hold your
> coins 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 common
> meme within the Bitcoin community.
> <!-- The above misspelling may be corrected if it is considered
> to be in bad taste.  -->
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--001a114853be46855305554f6590
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div>Hi ZmnSCPxj,<br><br></div>Few tho=
ughts about your proposal:<br></div>1- I kinda like the idea and I would pr=
obably use it, but still I believe it is a very limited use case and probab=
ly most wallet providers will not be interested in supporting it.<br></div>=
2- Early adopters and people highly involved in the community may appreciat=
e the &quot;hodl&quot; part in the redemption code, but it could cause conf=
usion in normal users not understanding the reference.<br><br></div>Regardi=
ng the time-zone I think the best option is to stick the UTC standard, usin=
g UTC+14 could be confusing since it is very unusual=C2=A0 and we are not u=
sed to deal with it.<br><br></div><br></div><div class=3D"gmail_extra"><br>=
<div class=3D"gmail_quote">On 12 July 2017 at 10:30, ZmnSCPxj via bitcoin-d=
ev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundatio=
n.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div>Good morning mailinglist,<=
br></div><div><br></div><div>I am saddened at the lack of attention to this=
 BIP proposal.=C2=A0 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 leas=
t some value to long-term investors.<br></div><div><br></div><div>So far I =
have seen only a single public feedback:<br></div><div><br></div><div><a hr=
ef=3D"https://www.reddit.com/r/Bitcoin/comments/6lzpvz/bip_hodl/djxzbvi/" t=
arget=3D"_blank">https://www.reddit.com/r/<wbr>Bitcoin/comments/6lzpvz/bip_=
<wbr>hodl/djxzbvi/</a><br></div><div><br></div><div>Basically, the point in=
 that feedback is mostly that the computed timelock should be UTC+0 0000h o=
f the given human-readable date.<br></div><div><br></div><div>I would like =
to respectfully ask the mailing list about which option is best:<br></div><=
div><br></div><div>1.=C2=A0 (current) Use the earliest timezone as of now, =
UTC+14 0000h of the given human-readable date.=C2=A0 Pro: No matter where y=
ou are in the world, as soon as the given date arrives, the fund can be spe=
nt.=C2=A0 Con: For most of the world, the fund can be spent on some time th=
e day before, or even two days before for UTC-11 and UTC-12 timezones.<br><=
/div><div><br></div><div>2.=C2=A0 Use the standard timezone UTC+0 0000h of =
the given human-readable date.=C2=A0 Pro: standard time.=C2=A0 Con: for hal=
f of the world, the fund is not spendable until some time into the given da=
te, for the other half, it will be spendable at an earlier date.<br></div><=
div><br></div><div>3.=C2=A0 Allow indicating a timezone to the human-readab=
le part.=C2=A0 Pro: gives control over the user&#39;s expected local time.=
=C2=A0 Con: additional field and effectively more control, need to handle a=
lso strange timezones that have 0.5 hour difference from UTC, need to encod=
e positive and negative preferably without using + and -, as those may brea=
k double-click selection.<br></div><div><br></div><div>I hope to get some f=
eedback from this list.<br></div><div><br></div><div>Regards,<br></div><div=
>ZmnSCPxj<br></div><div><br></div><div>-------- Original Message --------<b=
r></div><div>Subject: [bitcoin-dev] [BIP Proposal] Standard address format =
for timelocked funds<br></div><div>Local Time: July 8, 2017 9:13 AM<br></di=
v><div>UTC Time: July 8, 2017 1:13 AM<br></div><div>From: <a href=3D"mailto=
:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists=
.<wbr>linuxfoundation.org</a><br></div><div>To: bitcoin-dev &lt;<a href=3D"=
mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev=
@lists.<wbr>linuxfoundation.org</a>&gt;<br></div><div><br></div><div><br></=
div><div>&lt;pre&gt;<br></div><div>BIP: ?<br></div><div>Title: Standard add=
ress format for timelocked funds<br></div><div>Author: ZmnSCPxj &lt;<a href=
=3D"mailto:ZmnSCPxj@protonmail.com" target=3D"_blank">ZmnSCPxj@protonmail.c=
om</a>&gt;<br></div><div>Comments-Summary: ?<br></div><div>Comments-URI: ?<=
br></div><div>Status: ?<br></div><div>Type: ?<br></div><div>Created: 2017-0=
7-01<br></div><div>License: CC0-1.0<br></div><div>&lt;/pre&gt;<br></div><di=
v><br></div><div>=3D=3D Abstract =3D=3D<br></div><div><br></div><div>&lt;co=
de&gt;OP_CHECKLOCKTIMEVERIFY&lt;/<wbr>code&gt; provides a method of<br></di=
v><div>locking funds until a particular time arrives.<br></div><div>One pot=
ential use of this opcode is for a user to precommit<br></div><div>himself =
or herself to not spend funds until a particular<br></div><div>date, i.e. t=
o hold the funds until a later date.<br></div><div><br></div><div>This prop=
osal adds a format for specifying addresses that<br></div><div>precommit to=
 timelocked funds, as well as specifying a<br></div><div>redemption code to=
 redeem funds after the timelock has<br></div><div>passed.<br></div><div>Th=
is allows ordinary non-technical users to make use of<br></div><div>&lt;cod=
e&gt;OP_CHECKLOCKTIMEVERIFY&lt;/<wbr>code&gt; easily.<br></div><div><br></d=
iv><div>=3D=3D Copyright =3D=3D<br></div><div><br></div><div>This BIP is re=
leased under CC0-1.0.<br></div><div><br></div><div>=3D=3D Specification =3D=
=3D<br></div><div><br></div><div>This proposal provides formats for specify=
ing an<br></div><div>address that locks funds until a specified date,<br></=
div><div>and a redemption code that allows the funds to be<br></div><div>sw=
ept on or after the specified date.<br></div><div><br></div><div>At minimum=
, wallet software supporting this BIP must<br></div><div>be capable of swee=
ping the redemption code on or after<br></div><div>the specified date.<br><=
/div><div>In addition, the wallet software should support sending<br></div>=
<div>funds to the timelocked address specified here.<br></div><div>Finally,=
 wallet software may provide a command to create<br></div><div>a pair of ti=
melocked address and redemption code.<br></div><div><br></div><div>Addresse=
s and redemption codes are encoded using<br></div><div>[<a href=3D"https://=
github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#Bech32" target=3D"_b=
lank">https://github.com/bitcoin/<wbr>bips/blob/master/bip-0173.<wbr>mediaw=
iki#Bech32</a><br></div><div>Bech32 encoding].<br></div><div><br></div><div=
>=3D=3D=3D Timelocked Address Format =3D=3D=3D<br></div><div><br></div><div=
>The human-readable part of the address is composed of:<br></div><div><br><=
/div><div># The four characters &lt;code&gt;hodl&lt;/code&gt;.<br></div><di=
v># A date, in &lt;code&gt;YYYYMMDD&lt;/code&gt; form.=C2=A0 For example,<b=
r></div><div>=C2=A0 the date August 1, 2017 is encoded as &lt;code&gt;20170=
801&lt;/code&gt;.<br></div><div># A network code, either &lt;code&gt;tb&lt;=
/code&gt; for testnet,<br></div><div>=C2=A0 or &lt;code&gt;bc&lt;/code&gt; =
for Bitcoin mainnet.<br></div><div><br></div><div>The data part of the addr=
ess is composed of:<br></div><div><br></div><div># A version quintet (5 bit=
s), which must be 0 for this<br></div><div>=C2=A0 BIP.<br></div><div># A pu=
blic key hash, 32 quintets (160 bits).=C2=A0 As is<br></div><div>=C2=A0 usu=
al for Bitcoin, this is big-endian.<br></div><div><br></div><div>This is to=
 be interpreted as follows:<br></div><div><br></div><div># The given date i=
s the first day that the funds in<br></div><div>=C2=A0 the given address ma=
y be redeemed.<br></div><div># The funds are owned by whoever controls the =
private<br></div><div>=C2=A0 key corresponding to the public key hash given=
.<br></div><div><br></div><div>=3D=3D=3D Redemption Code =3D=3D=3D<br></div=
><div><br></div><div>The human-readable part of the redemption code is<br><=
/div><div>composed of:<br></div><div><br></div><div># The four characters &=
lt;code&gt;hedl&lt;/code&gt;.<br></div><div># A date, in &lt;code&gt;YYYYMM=
DD&lt;/code&gt; form.<br></div><div># A network code, either &lt;code&gt;tb=
&lt;/code&gt; for testnet,<br></div><div>=C2=A0 or &lt;code&gt;bc&lt;/code&=
gt; for Bitcoin mainnet.<br></div><div><br></div><div>The data part of the =
address is composed of:<br></div><div><br></div><div># A version quintet (5=
 bits), which must be 0 for this<br></div><div>=C2=A0 BIP.<br></div><div># =
A private key, 52 quintets (260 bits).=C2=A0 This is the<br></div><div>=C2=
=A0 256-bit private key, prepended with 4 &lt;code&gt;0&lt;/code&gt;<br></d=
iv><div>=C2=A0 bits, in big-endian order.=C2=A0=C2=A0 &lt;!-- We could cons=
ider<br></div><div>=C2=A0 some kind of mini private key instead if the secu=
rity<br></div><div>=C2=A0 is similar anyway.=C2=A0 --&gt;<br></div><div><br=
></div><div>This is to be interpreted as follows:<br></div><div><br></div><=
div># The given date is the first day that the funds in<br></div><div>=C2=
=A0 the given address may be redeemed.<br></div><div># The private key unlo=
cks the funds.<br></div><div><br></div><div>=3D=3D=3D Lock Time Computation=
 =3D=3D=3D<br></div><div><br></div><div>Given a particular lock date &lt;co=
de&gt;YYYYMMDD&lt;/code&gt;, the<br></div><div>actual lock time is computed=
 as follows:<br></div><div><br></div><div># The day before the lock date is=
 taken.=C2=A0 For example,<br></div><div>=C2=A0 if the lock date is &lt;cod=
e&gt;20180101&lt;/code&gt; or<br></div><div>=C2=A0 January 1, 2018, we take=
 the date December 31, 2017.<br></div><div># We take the time 1000h (10:00 =
AM, or 10 in the morning)<br></div><div>=C2=A0 of the date from the above s=
tep.<br></div><div><br></div><div>This lock time is then translated to a<br=
></div><div>Unix epoch time, as per POSIX.1-2001 (which removes the<br></di=
v><div>buggy day February 29, 2100 in previous POSIX revisions).<br></div><=
div>The translation should use, at minimum, unsigned 32-bit<br></div><div>n=
umbers to represent the Unix epoch time.<br></div><div><br></div><div>The U=
nix epoch time shall then be interpreted as an<br></div><div>&lt;code&gt;nL=
ockTime&lt;/code&gt; value, as per standard Bitcoin.<br></div><div>Whether =
it is possible to represent dates past 2038<br></div><div>will depend on wh=
ether standard Bitcoin can represent<br></div><div>&lt;code&gt;nLockTime&lt=
;/code&gt; values to represent dates past<br></div><div>2038.<br></div><div=
>Since &lt;code&gt;nLockTime&lt;/code&gt; is an unsigned 32-bit<br></div><d=
iv>value, it should be possible to represent dates until<br></div><div>06:2=
8:15 UTC+0 2106-02-07.<br></div><div>Future versions of Bitcoin should be a=
ble to support<br></div><div>&lt;code&gt;nLockTime&lt;/code&gt; larger than=
 unsigned 32-bit,<br></div><div>in order to allow even later dates.<br></di=
v><div><br></div><div>The reason for using an earlier lock time than the<br=
></div><div>specified date is given in the Rationale section of<br></div><d=
iv>this BIP.<br></div><div><br></div><div>=3D=3D=3D Payment to a Timelocked=
 Address =3D=3D=3D<br></div><div><br></div><div>An ordinary P2SH payment is=
 used to provide funds to a<br></div><div>timelocked address.<br></div><div=
><br></div><div>The script below is used as the &lt;code&gt;redeemScript&lt=
;/code&gt;<br></div><div>for the P2SH payment:<br></div><div><br></div><div=
>&lt;timeout&gt; OP_CHECKLOCKTIMEVERIFY OP_DROP<br></div><div>OP_DUP OP_HAS=
H160 &lt;publickeyhash&gt; OP_EQUALVERIFY OP_CHECKSIG<br></div><div><br></d=
iv><div>Once the &lt;code&gt;redeemScript&lt;/code&gt; is derived, the hash=
 is<br></div><div>determined, and an ordinary P2SH output with the below<br=
></div><div>&lt;code&gt;scriptPubKey&lt;/code&gt; used:<br></div><div><br><=
/div><div>OP_HASH160 &lt;redeemScripthash&gt; OP_EQUAL<br></div><div><br></=
div><div>In case of SegWit deployment, SegWit-compatible wallets<br></div><=
div>should be able to use P2SH, P2WSH, or P2SH-P2WSH, as per<br></div><div>=
the output they would normally use in that situation.<br></div><div><br></d=
iv><div>Obviously, a timelocked address has an equivalent<br></div><div>Bit=
coin &lt;code&gt;3&lt;/code&gt; (P2SH) address.<br></div><div>A simple serv=
ice or software that translates from a<br></div><div>public timelocked addr=
ess to a P2SH address can be<br></div><div>created that makes timelocking (=
but not redemption)<br></div><div>backwards compatible with wallets that do=
 not support<br></div><div>this BIP.<br></div><div><br></div><div>This prop=
osal recommends that wallets supporting payment<br></div><div>to P2PKH, P2S=
H, P2WPKH, and P2WSH Bitcoin addresses should<br></div><div>reuse the same =
interface for paying to such addresses as<br></div><div>paying into timeloc=
ked addresses of this proposal.<br></div><div><br></div><div>=3D=3D=3D Rede=
mption of a Timelocked Redemption Code =3D=3D=3D<br></div><div><br></div><d=
iv>To sweep a timelocked redemption code after the timelock,<br></div><div>=
one must provide the given &lt;code&gt;redeemScript&lt;/code&gt; as<br></di=
v><div>part of the &lt;code&gt;scriptSig&lt;/code&gt;, of all unspent<br></=
div><div>outputs that pay to the given &lt;code&gt;redeemScript&lt;/code&gt=
;<br></div><div>hash.<br></div><div><br></div><div>When sweeping a timelock=
ed redemption code, first the<br></div><div>wallet must extract the private=
 key from the redemption<br></div><div>code, then derive the public key, th=
e public key hash,<br></div><div>the &lt;code&gt;redeemScript&lt;/code&gt;,=
 and finally the<br></div><div>&lt;code&gt;redeemScript&lt;/code&gt; hash.<=
br></div><div><br></div><div>Then, the wallet must find all unspent outputs=
 that pay<br></div><div>to the &lt;code&gt;redeemScript&lt;/code&gt; hash v=
ia P2SH (and, in the<br></div><div>case of SegWit deployment, via P2SH-P2WS=
H and P2WSH).<br></div><div><br></div><div>For each such output, the wallet=
 then generates a<br></div><div>transaction input with the below &lt;code&g=
t;scriptSig&lt;/code&gt;, as<br></div><div>per usual P2SH redemptions:<br><=
/div><div><br></div><div>&lt;signature&gt; &lt;pubkey&gt; &lt;redeemScript&=
gt;<br></div><div><br></div><div>The wallet then outputs to an address it c=
an control.<br></div><div><br></div><div>As the Script involved uses &lt;co=
de&gt;OP_CHECKLOCKTIMEVERIFY&lt;/<wbr>code&gt;,<br></div><div>the &lt;code&=
gt;nSequence&lt;/code&gt; must be 0 and the<br></div><div>&lt;code&gt;nLock=
Time&lt;/code&gt; must be equal to the computed<br></div><div>lock time.<br=
></div><div>This implies that the transaction cannot be transmitted<br></di=
v><div>(and the funds cannot be sweeped)<br></div><div>until after the give=
n lock time.<br></div><div><br></div><div>The above procedure is roughly id=
entical to sweeping an<br></div><div>ordinary, exported private key.<br></d=
iv><div><br></div><div>This proposal recommends that wallets supporting a s=
weep<br></div><div>function should reuse the same interface for sweeping<br=
></div><div>individual private keys (wallet import format) for sweeping<br>=
</div><div>timelocked redemption codes.<br></div><div><br></div><div>=3D=3D=
 Motivation =3D=3D<br></div><div><br></div><div>A key motivation for this B=
IP is to allow easy use of<br></div><div>&lt;code&gt;OP_CHECKLOCKTIMEVERIFY=
&lt;/<wbr>code&gt; by end-users.<br></div><div><br></div><div>The below are=
 expected use cases of this proposal:<br></div><div><br></div><div># A user=
 wants to purchase an amount of Bitcoin,<br></div><div>and subsequently wai=
t for an amount of time before<br></div><div>cashing out.<br></div><div>The=
 user fears that he or she may have &quot;weak hands&quot;,<br></div><div>i=
.e. sell unfavorably on a temporary dip, and thus<br></div><div>commits the=
 coins into a timelocked fund that can<br></div><div>only be opened after a=
 specific date.<br></div><div># A user wants to gift an amount of Bitcoins =
to<br></div><div>an infant or minor, and wants the fund to not be spent<br>=
</div><div>on ill-advised purchases until the infant or minor<br></div><div=
>reaches the age of maturity.<br></div><div># A user may wish to prepare so=
me kind of monthly subsidy<br></div><div>or allowance to another user, and =
prepares a series of<br></div><div>timelocked addresses, redeemable at some=
 set date on<br></div><div>each month, and provides the private redemption =
codes to<br></div><div>the beneficiary.<br></div><div># A user may fear dur=
ess or ransom for a particular<br></div><div>future time horizon, and volun=
tarily impose a lock time<br></div><div>during which a majority of their fu=
nds cannot be spent.<br></div><div><br></div><div>=3D=3D Rationale =3D=3D<b=
r></div><div><br></div><div>While in principle, this proposal may be implem=
ented as a<br></div><div>separate service or software, we should consider t=
he long<br></div><div>time horizons that may be desired by users.<br></div>=
<div>A user using a particular software to timelock a fund may<br></div><di=
v>have concerns, for example, of specifying a timelock<br></div><div>18 yea=
rs in the future for a gift or inheritance to a<br></div><div>newborn infan=
t.<br></div><div>The software or service may no longer exist after 18 years=
,<br></div><div>unless the user himself or herself takes over maintenance<b=
r></div><div>of that software or service.<br></div><div>By having a single =
standard for timelocked funds that is<br></div><div>shared and common among=
 multiple implementations of Bitcoin<br></div><div>wallets, the user has so=
me assurance that the redemption code<br></div><div>for the funds is still =
useable after 18 years.<br></div><div>Further, a publicly-accessible standa=
rd specifying how the<br></div><div>funds can be redeemed will allow techni=
cally-capable users<br></div><div>or beneficiaries to create software that =
can redeem the<br></div><div>timelocked fund.<br></div><div><br></div><div>=
This proposal provides a timelock at the granularity of a<br></div><div>day=
.<br></div><div>The expectation is that users will have long time<br></div>=
<div>durations of months or years, so that the ability to<br></div><div>spe=
cify exact times, which would require specifying the<br></div><div>timezone=
, is unneeded.<br></div><div><br></div><div>The actual timeout used is 1000=
h of the day before the<br></div><div>human-readable date, so that timezone=
s of UTC+14 will<br></div><div>definitely be able to redeem the money start=
ing at<br></div><div>0000h of the human-readable date, local time (UTC+14).=
<br></div><div>Given the expectation that users will use long time<br></div=
><div>durations, the fact that timezones of UTC-12 will<br></div><div>actua=
lly be able to redeem the funds on 2200h UTC-12<br></div><div>time two days=
 before can be considered an acceptable<br></div><div>error.<br></div><div>=
<br></div><div>The human-readable date is formatted according to<br></div><=
div>[<a href=3D"https://www.iso.org/iso-8601-date-and-time-format.html" tar=
get=3D"_blank">https://www.iso.org/iso-8601-<wbr>date-and-time-format.html<=
/a><br></div><div>ISO standard dates], with the dashes removed.<br></div><d=
iv>Dashes may prevent double-click selection, making<br></div><div>usabilit=
y of these addresses less desirable.<br></div><div>&lt;!--<br></div><div>We=
 can consider something like 2021m12d11 instead,<br></div><div>which would =
be much more readable and understandable<br></div><div>to human users.<br><=
/div><div>--&gt;<br></div><div><br></div><div>The &lt;code&gt;bc&lt;/code&g=
t; or &lt;code&gt;tb&lt;/code&gt; is after the<br></div><div>date since the=
 date is composed of digits and the bech32<br></div><div>separator itself i=
s the digit &lt;code&gt;1&lt;/code&gt;.=C2=A0 One<br></div><div>simply need=
s to compare &lt;code&gt;hedlbc202111211...&lt;/<wbr>code&gt;<br></div><div=
>and &lt;code&gt;hedl20211121bc1...&lt;/<wbr>code&gt;.<br></div><div><br></=
div><div>A version quintet is added in case of a future<br></div><div>socio=
political event that changes interpretation of<br></div><div>dates, or chan=
ges in scripting that would allow for more<br></div><div>efficient redempti=
ons of timelocked funds (which would<br></div><div>change the &lt;code&gt;r=
edeemScript&lt;/code&gt; paid to), or changes<br></div><div>in the size and=
/or format of lock times, and so on.<br></div><div>Such changes are unlikel=
y, so the version is a quintet in<br></div><div>the bech32 data part rather=
 than a substring in the<br></div><div>human-readable part.<br></div><div><=
br></div><div>The public address format uses the &lt;code&gt;hodl&lt;/code&=
gt; as<br></div><div>the start of the code, while the private key (the<br><=
/div><div>redemption code) uses &lt;code&gt;hedl&lt;/code&gt;.<br></div><di=
v>This provides a simple mnemonic for users:<br></div><div>&quot;Pay into t=
he &lt;code&gt;hodl&lt;/code&gt; code to hold your<br></div><div>coins unti=
l the given date.<br></div><div>After you&#39;ve held the coins (on or afte=
r the given date)<br></div><div>use the &lt;code&gt;hedl&lt;/code&gt; code =
to redeem the coins.&quot;<br></div><div>The obvious misspelling of &quot;h=
odl&quot; is a homage to the common<br></div><div>meme within the Bitcoin c=
ommunity.<br></div><div>&lt;!-- The above misspelling may be corrected if i=
t is considered<br></div><div>to be in bad taste.=C2=A0 --&gt;<br></div><br=
>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--001a114853be46855305554f6590--