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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <laanwj@gmail.com>) id 1X6yPL-00029y-SG
for bitcoin-development@lists.sourceforge.net;
Tue, 15 Jul 2014 08:48:19 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.178 as permitted sender)
client-ip=209.85.223.178; envelope-from=laanwj@gmail.com;
helo=mail-ie0-f178.google.com;
Received: from mail-ie0-f178.google.com ([209.85.223.178])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1X6yPK-0000LJ-4X
for bitcoin-development@lists.sourceforge.net;
Tue, 15 Jul 2014 08:48:19 +0000
Received: by mail-ie0-f178.google.com with SMTP id tp5so4273039ieb.9
for <bitcoin-development@lists.sourceforge.net>;
Tue, 15 Jul 2014 01:48:12 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.32.73 with SMTP id g9mr4273105igi.31.1405414092809; Tue,
15 Jul 2014 01:48:12 -0700 (PDT)
Received: by 10.64.135.66 with HTTP; Tue, 15 Jul 2014 01:48:12 -0700 (PDT)
In-Reply-To: <CAJHLa0OskyEbsEmhrUayshg56Cr_q_6O4edRmdM5jDh3Pb=WGA@mail.gmail.com>
References: <CAJHLa0M7iEUQnJ9M4A3ev3EQqxUVQG85qucRamvMb0n-CztOFA@mail.gmail.com>
<CA+s+GJCJ77FkRGzTNLxOaJifKWLeC2wJ5usYf571MVOOugtMRQ@mail.gmail.com>
<CAJHLa0OskyEbsEmhrUayshg56Cr_q_6O4edRmdM5jDh3Pb=WGA@mail.gmail.com>
Date: Tue, 15 Jul 2014 10:48:12 +0200
Message-ID: <CA+s+GJABgJ0XCovZ+UW1ckSpdM_Yet2xaNx2-MGXMLaATN3hyQ@mail.gmail.com>
From: Wladimir <laanwj@gmail.com>
To: Jeff Garzik <jgarzik@bitpay.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(laanwj[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1X6yPK-0000LJ-4X
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bitcoin address TTL & key expiration?
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 15 Jul 2014 08:48:20 -0000
On Tue, Jul 15, 2014 at 10:23 AM, Jeff Garzik <jgarzik@bitpay.com> wrote:
> On Tue, Jul 15, 2014 at 4:19 AM, Wladimir <laanwj@gmail.com> wrote:
> There are major gaps that the payment protocol doesn't cover.
>
> There are several deployed use cases where you are provided/request an
> address, an API provides one, and one or more incoming payments arrive
> as the user sends them over minutes/hours/days/weeks.
Couldn't these services return a payment message instead of an address?
I agree that there is currently an UI issue here: there is no way in
current wallets to store a payment message and pay to it later. We
will need something like that for recurring payments as well.
Bitcoin addresses were never designed with extensibility in mind.
Before the payment protocol there have been lots of ideas to add
functionality to them, but the underlying idea that they have to be
handled by users manually means that they have to be as short as
possible, which is a conflicting aim with extensibility...
Wladimir
|
