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-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1WTUvR-0003Lo-Uy for bitcoin-development@lists.sourceforge.net;
Fri, 28 Mar 2014 11:26:17 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of m.gmane.org
designates 80.91.229.3 as permitted sender)
client-ip=80.91.229.3;
envelope-from=gcbd-bitcoin-development@m.gmane.org;
helo=plane.gmane.org;
Received: from plane.gmane.org ([80.91.229.3])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1WTUvQ-0003q1-DE
for bitcoin-development@lists.sourceforge.net;
Fri, 28 Mar 2014 11:26:17 +0000
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1WTUvF-0003R9-Fm for bitcoin-development@lists.sourceforge.net;
Fri, 28 Mar 2014 12:26:05 +0100
Received: from f052145073.adsl.alicedsl.de ([78.52.145.73])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00 for <bitcoin-development@lists.sourceforge.net>;
Fri, 28 Mar 2014 12:26:05 +0100
Received: from andreas by f052145073.adsl.alicedsl.de with local (Gmexim 0.1
(Debian)) id 1AlnuQ-0007hv-00
for <bitcoin-development@lists.sourceforge.net>;
Fri, 28 Mar 2014 12:26:05 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: bitcoin-development@lists.sourceforge.net
From: Andreas Schildbach <andreas@schildbach.de>
Date: Fri, 28 Mar 2014 12:25:53 +0100
Message-ID: <lh3m7i$v18$1@ger.gmane.org>
References: <CANEZrP0AwR3WgHfwYWcrC9Z_MHPDwymWXAQwp7D8XZ+o2FsK8g@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: f052145073.adsl.alicedsl.de
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.4.0
In-Reply-To: <CANEZrP0AwR3WgHfwYWcrC9Z_MHPDwymWXAQwp7D8XZ+o2FsK8g@mail.gmail.com>
X-Enigmail-Version: 1.5.2
X-Spam-Score: -0.8 (/)
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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [80.91.229.3 listed in list.dnswl.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
1.1 DKIM_ADSP_ALL No valid author signature,
domain signs all mail
-0.0 SPF_PASS SPF: sender matches SPF record
-0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1WTUvQ-0003q1-DE
Subject: Re: [Bitcoin-development] BIP 70 refund field
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: Fri, 28 Mar 2014 11:26:18 -0000
I see the problem.
However, I don't see how PaymentDetails can be an answer. None of the
fields (other than outputs and network) can be known in advance (at the
time of the initial payment).
You're probably aiming for an expires field? How would you refund a
payment after expiry? Note its not your choice wether to refund a
payment -- it can be ordered by a court years after the payment happened.
Btw. another problem is that the refund address is currently unprotected.
On 03/28/2014 12:07 PM, Mike Hearn wrote:
> Modern devices like smartphones and tablets do not have swap files. This
> design is chosen to ensure responsive, fluid UI that can avoid blocking
> on disk regardless of how much multi-tasking is done, but it creates
> ripples that impact everything else.
>
> One implication of this is that on these devices, we cannot store all
> keys or transactions in memory forever. BIP 70 has an expiry field for
> PaymentRequests that we can use to allow us to eventually stop loading
> those keys into RAM - at that point payments to those keys would no
> longer be recognised. But there's no equivalent for refund addresses.
>
> More generally, though we re-used the output structure to define the
> refund, we didn't (for some reason that I forgot) reuse PaymentDetails,
> even though the payment details for a refund are indeed PaymentDetails.
>
> Though I am loathe to go back and redesign this part of BIP 70 so soon
> after we shipped v1, it seems to me like the refund feature may be hard
> to implement on phones if there's no time limit for when you can receive
> a refund. Otherwise a wallet has to be looking out for refunds for
> payments you may have made years ago. So perhaps we should add a new
> refund field that embeds a PaymentDetails structure instead of being
> just a list of outputs.
>
> We could try and solve this problem some other way purely internally, by
> doing a kind of wallet-specific swapping process in which things like
> Bloom filters are calculated without all keys in them being held in
> memory at once (perhaps caching filters for old parts of the key chain
> on disk), so you can have "infinite" wallets, but eventually the huge
> Bloom filters that would result would hurt efficiency in other ways. So
> key expiry seems pretty fundamental to scalability.
>
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
|
