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; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
Date: Fri, 28 Mar 2014 12:07:04 +0100
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
Subject: [Bitcoin-development] BIP 70 refund field
Precedence: list

--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&#39;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&#39;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&#39;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 &quot;infinite&quot; 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--