summaryrefslogtreecommitdiff
path: root/c9/9aab5d72b3d09c9afbacd936ebfe739682758b
blob: 81d1698ad3e4d6e62b669585c4a5aaf2b5237848 (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
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1X75Yb-0001uT-JB
	for bitcoin-development@lists.sourceforge.net;
	Tue, 15 Jul 2014 16:26:21 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.218.45 as permitted sender)
	client-ip=209.85.218.45; envelope-from=mh.in.england@gmail.com;
	helo=mail-oi0-f45.google.com; 
Received: from mail-oi0-f45.google.com ([209.85.218.45])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1X75Ya-0005SN-PV
	for bitcoin-development@lists.sourceforge.net;
	Tue, 15 Jul 2014 16:26:21 +0000
Received: by mail-oi0-f45.google.com with SMTP id e131so110992oig.32
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 15 Jul 2014 09:26:15 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.144.161 with SMTP id sn1mr12078036obb.82.1405441575232; 
	Tue, 15 Jul 2014 09:26:15 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.35.234 with HTTP; Tue, 15 Jul 2014 09:26:15 -0700 (PDT)
In-Reply-To: <CAJHLa0M9UC+7D+5NK7eHMPMPJb+K-eqpGC77t4ikKLz76GtVPw@mail.gmail.com>
References: <CAJHLa0M7iEUQnJ9M4A3ev3EQqxUVQG85qucRamvMb0n-CztOFA@mail.gmail.com>
	<201407151448.57223.luke@dashjr.org>
	<CAJHLa0Nj2f4mSKNggGH4sXZTLYNwdVGO7uMSzN7V_vVKU-6w9Q@mail.gmail.com>
	<201407151541.53342.luke@dashjr.org>
	<CAJHLa0M9UC+7D+5NK7eHMPMPJb+K-eqpGC77t4ikKLz76GtVPw@mail.gmail.com>
Date: Tue, 15 Jul 2014 18:26:15 +0200
X-Google-Sender-Auth: NinEk7SYt9aB--Ie3rwP0E6zjCo
Message-ID: <CANEZrP1n+oK1_OH2njmYy0S9J1qLb9MqHF2HY6NONovwB9bC0A@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Jeff Garzik <jgarzik@bitpay.com>
Content-Type: multipart/alternative; boundary=089e0158ac78d82a7d04fe3ddd91
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: 1X75Ya-0005SN-PV
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 16:26:21 -0000

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

>
> Actually, and this is key, there _are_ reasons why deposits might not
> be able to use PaymentRequests.  Payments happen even when
> wallets/computers are offline.
>

I don't understand this point. It's the *sender* that is parsing the
PaymentRequest and following the instructions. By definition the sender
must be online. A computer that is switched off cannot sign a transaction
at all.


> If you have negotiated HD wallet details, you can use a new address
> every time, as mentioned.


Yes, and an extension to BIP 70 to allow for this (or stealth addresses or
whatever) has been discussed several times.

This thread started by proposing (I think) an expiry time for addresses.
BIP70 satisfies this use case, I think we all agree on that. Now for cases
where someone can't use BIP70 for whatever reason, or it's suboptimal,
absolutely we should design extensions to fix that.

--089e0158ac78d82a7d04fe3ddd91
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"><div class=3D"">Actually, and this is key, there=
 _are_ reasons why deposits might not<br>
</div>
be able to use PaymentRequests. =C2=A0Payments happen even when<br>
wallets/computers are offline.<br></blockquote><div><br></div><div>I don&#3=
9;t understand this point. It&#39;s the <i>sender</i>=C2=A0that is parsing =
the PaymentRequest and following the instructions. By definition the sender=
 must be online. A computer that is switched off cannot sign a transaction =
at all.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">If you have negotiated HD w=
allet details, you can use a new address<br>
every time, as mentioned.</blockquote><div><br></div><div>Yes, and an exten=
sion to BIP 70 to allow for this (or stealth addresses or whatever) has bee=
n discussed several times.</div><div><br></div><div>This thread started by =
proposing (I think) an expiry time for addresses. BIP70 satisfies this use =
case, I think we all agree on that. Now for cases where someone can&#39;t u=
se BIP70 for whatever reason, or it&#39;s suboptimal, absolutely we should =
design extensions to fix that.</div>
</div></div></div>

--089e0158ac78d82a7d04fe3ddd91--