summaryrefslogtreecommitdiff
path: root/7c/87479052f6b882a6b0035830b319d850136389
blob: bb6679480556712cf9a59ef5d7fa0d42564530ac (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
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1X74Uy-0003AS-OI
	for bitcoin-development@lists.sourceforge.net;
	Tue, 15 Jul 2014 15:18:32 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.181 as permitted sender)
	client-ip=209.85.214.181; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f181.google.com; 
Received: from mail-ob0-f181.google.com ([209.85.214.181])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1X74Ux-0007Eo-T9
	for bitcoin-development@lists.sourceforge.net;
	Tue, 15 Jul 2014 15:18:32 +0000
Received: by mail-ob0-f181.google.com with SMTP id va2so4037760obc.40
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 15 Jul 2014 08:18:26 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.144.161 with SMTP id sn1mr11539696obb.82.1405437506404; 
	Tue, 15 Jul 2014 08:18:26 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.35.234 with HTTP; Tue, 15 Jul 2014 08:18:26 -0700 (PDT)
In-Reply-To: <CAJHLa0Nj2f4mSKNggGH4sXZTLYNwdVGO7uMSzN7V_vVKU-6w9Q@mail.gmail.com>
References: <CAJHLa0M7iEUQnJ9M4A3ev3EQqxUVQG85qucRamvMb0n-CztOFA@mail.gmail.com>
	<201407151448.57223.luke@dashjr.org>
	<CAJHLa0Nj2f4mSKNggGH4sXZTLYNwdVGO7uMSzN7V_vVKU-6w9Q@mail.gmail.com>
Date: Tue, 15 Jul 2014 17:18:26 +0200
X-Google-Sender-Auth: MIFj9Xvr6bDLieNl5IDJAPYYcG4
Message-ID: <CANEZrP30PLQAebOkoLUphR+6wnwyE7K_BX=bszF8T5UPvai-Lg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Jeff Garzik <jgarzik@bitpay.com>
Content-Type: multipart/alternative; boundary=089e0158ac7852eb5804fe3ceb39
X-Spam-Score: -0.5 (/)
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
	(mh.in.england[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	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: 1X74Ux-0007Eo-T9
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 15:18:33 -0000

--089e0158ac7852eb5804fe3ceb39
Content-Type: text/plain; charset=UTF-8

>
> 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 :)

--089e0158ac7852eb5804fe3ceb39
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">Payment protocol just doesn&#39;t well the use c=
ases of,<br>

* an on-going payment stream from, e.g. Eligius to coinbase<br>
* deposit addresses and deposit situations</blockquote><div><br></div><div>=
This seems to be the key point of disagreement here. Wladimir and I think i=
t satisfies your requirement just fine. You disagree. Let&#39;s get to the =
bottom of that.</div>
<div><br></div><div>A PaymentRequest with a zero valued pay-to-address outp=
ut and an expiration time, base58 encoded, would look very much like your e=
xtended address form. I don&#39;t suggest anyone actually represents Paymen=
tRequest&#39;s using base58 but it helps to see the conceptual analogue. Th=
ere&#39;d be a bit more stuff in there like some varint and wiretype codes =
but we&#39;re talking a handful of bytes. Functionally, it&#39;d be identic=
al.</div>
<div><br></div><div>Places like protocols or APIs that require a piece of t=
ext and cannot handle a piece of binary data could be retrofitted into the =
new world by accepting base58 encoded PaymentRequest&#39;s. This would be k=
ind of silly because it&#39;s fundamentally binary data, but we already do =
this so it&#39;s at least consistently silly :)</div>
</div></div></div>

--089e0158ac7852eb5804fe3ceb39--