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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jgarzik@bitpay.com>) id 1X74lO-0004Ou-B6
for bitcoin-development@lists.sourceforge.net;
Tue, 15 Jul 2014 15:35:30 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of bitpay.com
designates 209.85.212.177 as permitted sender)
client-ip=209.85.212.177; envelope-from=jgarzik@bitpay.com;
helo=mail-wi0-f177.google.com;
Received: from mail-wi0-f177.google.com ([209.85.212.177])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1X74lN-0002vN-B4
for bitcoin-development@lists.sourceforge.net;
Tue, 15 Jul 2014 15:35:30 +0000
Received: by mail-wi0-f177.google.com with SMTP id ho1so4553298wib.10
for <bitcoin-development@lists.sourceforge.net>;
Tue, 15 Jul 2014 08:35:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc:content-type;
bh=bKhXyBkeoE7it9svRDzXXznorVn+j3TfG740AD5NnmE=;
b=W+116EIh4KBfW/tztLdtRC6RoW01QQ32qynzMp7UT+hLAsr6kWD/U9BFcepu1dcGXx
OvPb+P521db/P+NUKLIufPqMmW96t7OUjUSvLas2GagBL3eEZ3DZDD4gTRJYjpo/N+eu
4nG5/PMHh1Rpp27aLS9iBgmjddLXkuEKKAY/FQJDy6rTBsZo0efzPT/WaxCojPVvizI9
6nMdrsEK+jaNOVeyCLVN+tYCPq+v1QsVtnREVClCNG04o5qKl5+Cixs45GMIEbQU9cq/
OlvgpwVLjNOnATWk+yZNuHyvxVZA5XPAF04kA3T5EIWth+i0Jsy7arBTx9qjPPNK25cp
DxoA==
X-Gm-Message-State: ALoCoQkrc0WUfKq7raEL83ZbsocLpqedcJK4fi8n+klIGGF7BaLK8dYjHROE4Kzjt7RLKPZHkoq7
X-Received: by 10.181.11.232 with SMTP id el8mr6551985wid.57.1405438523060;
Tue, 15 Jul 2014 08:35:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.5.67 with HTTP; Tue, 15 Jul 2014 08:35:03 -0700 (PDT)
In-Reply-To: <CANEZrP30PLQAebOkoLUphR+6wnwyE7K_BX=bszF8T5UPvai-Lg@mail.gmail.com>
References: <CAJHLa0M7iEUQnJ9M4A3ev3EQqxUVQG85qucRamvMb0n-CztOFA@mail.gmail.com>
<201407151448.57223.luke@dashjr.org>
<CAJHLa0Nj2f4mSKNggGH4sXZTLYNwdVGO7uMSzN7V_vVKU-6w9Q@mail.gmail.com>
<CANEZrP30PLQAebOkoLUphR+6wnwyE7K_BX=bszF8T5UPvai-Lg@mail.gmail.com>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Tue, 15 Jul 2014 11:35:03 -0400
Message-ID: <CAJHLa0Nxav0+VUZoJuiBKXAMMFv1GeGTq0kSn_qeBTizsFRCSQ@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
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 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: 1X74lN-0002vN-B4
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Stephane Brossier <stephane@kill-bill.org>,
Pierre-Alexandre Meyer <pierre@kill-bill.org>
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 15:35:30 -0000
This is a well known problem of BIP 70 from day one, because BIP 70
functions at too-low a level.
What needs to be negotiated between parties is a _payment
relationship_ that exchanges HD wallet data. This is what is necessary
to establish and maintain an ongoing payment relationship.
BIP 70 is focused on singular payments with specific outputs and
values. BIP 70 wants to transmit an actual transaction. That does
not fit the use cases described.
Adding in a hack that makes zero-valued outputs behave different does
not change the granularity at which BIP 70 operates.
This is a key reason why I have not just ACK'd the BIP 70 subscription
stuff. Subscriptions are another example of a longer term payment
relationship. For such case, you want to exchange HD wallet payment
details. You do not send or receive outputs. You might not send
transactions directly to the party (coming instead asynchronously &
unpredictably via blockchain).
BIP 70 marries the _relationship_ with payment transmittal, and the
subscription extension does not change that.
Our "contract" language must get a bit smarter, and include HD wallet
payment details, not necessarily focus on outputs.
On Tue, Jul 15, 2014 at 11:18 AM, Mike Hearn <mike@plan99.net> wrote:
>> Payment protocol just doesn't well the use cases of,
>> * an on-going payment stream from, e.g. Eligius to coinbase
>> * deposit addresses and deposit situations
>
>
> This seems to be the key point of disagreement here. Wladimir and I think it
> satisfies your requirement just fine. You disagree. Let's get to the bottom
> of that.
>
> A PaymentRequest with a zero valued pay-to-address output and an expiration
> time, base58 encoded, would look very much like your extended address form.
> I don't suggest anyone actually represents PaymentRequest's using base58 but
> it helps to see the conceptual analogue. There'd be a bit more stuff in
> there like some varint and wiretype codes but we're talking a handful of
> bytes. Functionally, it'd be identical.
>
> Places like protocols or APIs that require a piece of text and cannot handle
> a piece of binary data could be retrofitted into the new world by accepting
> base58 encoded PaymentRequest's. This would be kind of silly because it's
> fundamentally binary data, but we already do this so it's at least
> consistently silly :)
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
|
