From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: From: Mike Hearn To: Bitcoin Dev 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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.

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.

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.

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.

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.


--001a1134a944ac272004f5a8b35e--