summaryrefslogtreecommitdiff
path: root/d8/195269952dac12ed778ad4136389285c1417cf
blob: 6c081d9ba3887e4b59a5f0629e88381e6953904d (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
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 5B97CBCE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 28 Sep 2017 16:59:35 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id F2A1C20C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 28 Sep 2017 16:59:34 +0000 (UTC)
Received: from ishibashi.localnet (unknown
	[IPv6:2001:470:5:265:a45d:823b:2d27:961c])
	(Authenticated sender: luke-jr)
	by zinan.dashjr.org (Postfix) with ESMTPSA id 4EE9938A0024;
	Thu, 28 Sep 2017 16:59:29 +0000 (UTC)
X-Hashcash: 1:25:170928:bitcoin-dev@lists.linuxfoundation.org::g68+kwN2ArbK+OKc:LN3q
X-Hashcash: 1:25:170928:andreas@schildbach.de::jo+3gUSyzJsGQ7M=:e9OB
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
	Andreas Schildbach <andreas@schildbach.de>
Date: Thu, 28 Sep 2017 16:59:26 +0000
User-Agent: KMail/1.13.7 (Linux/4.12.5-gentoo; KDE/4.14.34; x86_64; ; )
References: <20170927160654.GA12492@savin.petertodd.org>
	<B5DE4E92-C5B3-4C01-A148-E3C46C897323@sprovoost.nl>
	<oqj02k$fj9$1@blaine.gmane.org>
In-Reply-To: <oqj02k$fj9$1@blaine.gmane.org>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201709281659.27343.luke@dashjr.org>
X-Spam-Status: No, score=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,
	RP_MATCHES_RCVD autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Address expiration times should be added to
	BIP-173
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, 28 Sep 2017 16:59:35 -0000

On Thursday 28 September 2017 2:13:48 PM Andreas Schildbach via bitcoin-dev 
wrote:
> On 09/28/2017 02:43 PM, Sjors Provoost via bitcoin-dev wrote:
> >> This feels redundant to me; the payment protocol already has an
> >> expiration time.
> > 
> > The BIP-70 payment protocol has significant overhead and most importantly
> > requires back and forth. Emailing a bitcoin address or printing it on an
> > invoice is much easier, so I would expect people to keep doing that.
> 
> The payment request message is just as one-way as an address is. It is
> already being emailed and printed on an invoice, in fact it often acts
> as the invoice.
> 
> Even more problematic, if you were to include an expiry date in a
> BIP-173 address and put that into a payment request, wallets wouldn't be
> allowed to parse that expiry date from the script without violating the
> BIP70 spec.

Payment requests don't use and don't overlap with addresses. Maybe you could 
have an argument for serialising BIP70 payment requests in Bech32 as the new 
address format itself, but it doesn't make sense to talk about putting a 
Bech32 address *into* a payment request...

Luke