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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1WTUcx-0006BB-NH
for bitcoin-development@lists.sourceforge.net;
Fri, 28 Mar 2014 11:07:11 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.47 as permitted sender)
client-ip=209.85.219.47; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f47.google.com;
Received: from mail-oa0-f47.google.com ([209.85.219.47])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WTUcv-0003CU-W3
for bitcoin-development@lists.sourceforge.net;
Fri, 28 Mar 2014 11:07:11 +0000
Received: by mail-oa0-f47.google.com with SMTP id i11so5853867oag.6
for <bitcoin-development@lists.sourceforge.net>;
Fri, 28 Mar 2014 04:07:04 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.122.136 with SMTP id ls8mr1093377obb.52.1396004824555;
Fri, 28 Mar 2014 04:07:04 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.231 with HTTP; Fri, 28 Mar 2014 04:07:04 -0700 (PDT)
Date: Fri, 28 Mar 2014 12:07:04 +0100
X-Google-Sender-Auth: 8JcuhBUdbou1Ojrq6nJr_Znr5sA
Message-ID: <CANEZrP0AwR3WgHfwYWcrC9Z_MHPDwymWXAQwp7D8XZ+o2FsK8g@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a1134a944ac272004f5a8b35e
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: 1WTUcv-0003CU-W3
Subject: [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:07:11 -0000
--001a1134a944ac272004f5a8b35e
Content-Type: text/plain; charset=UTF-8
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.
--001a1134a944ac272004f5a8b35e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Modern devices like smartphones and tablets do not have sw=
ap files. This design is chosen to ensure responsive, fluid UI that can avo=
id blocking on disk regardless of how much multi-tasking is done, but it cr=
eates ripples that impact everything else.<div>
<br></div><div>One implication of this is that on these devices, we cannot =
store all keys or transactions in memory forever. BIP 70 has an expiry fiel=
d for PaymentRequests that we can use to allow us to eventually stop loadin=
g those keys into RAM - at that point payments to those keys would no longe=
r be recognised. But there's no equivalent for refund addresses.</div>
<div><br></div><div>More generally, though we re-used the output structure =
to define the refund, we didn't (for some reason that I forgot) reuse P=
aymentDetails, even though the payment details for a refund are indeed Paym=
entDetails.</div>
<div><br></div><div>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 y=
ou can receive a refund. Otherwise a wallet has to be looking out for refun=
ds 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.</div>
<div><br></div><div>We could try and solve this problem some other way pure=
ly internally, by doing a kind of wallet-specific swapping process in which=
things like Bloom filters are calculated without all keys in them being he=
ld in memory at once (perhaps caching filters for old parts of the key chai=
n on disk), so you can have "infinite" wallets, but eventually th=
e huge Bloom filters that would result would hurt efficiency in other ways.=
So key expiry seems pretty fundamental to scalability.</div>
<div><br></div><div><br></div></div>
--001a1134a944ac272004f5a8b35e--
|
