public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mike Hearn <mike@plan99.net>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: [Bitcoin-development] BIP 70 refund field
Date: Fri, 28 Mar 2014 12:07:04 +0100	[thread overview]
Message-ID: <CANEZrP0AwR3WgHfwYWcrC9Z_MHPDwymWXAQwp7D8XZ+o2FsK8g@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1739 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1919 bytes --]

             reply	other threads:[~2014-03-28 11:07 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-28 11:07 Mike Hearn [this message]
2014-03-28 11:25 ` [Bitcoin-development] BIP 70 refund field Andreas Schildbach
2014-03-28 11:31   ` Mike Hearn
2014-03-28 16:59     ` Andreas Schildbach
2014-03-28 18:19       ` Mike Hearn
2014-03-28 20:56         ` Andreas Schildbach
2014-03-29  9:27           ` Roy Badami
2014-03-29 13:29             ` Mike Hearn
2014-03-30 17:21               ` Andreas Schildbach
2014-03-28 11:38   ` Wladimir
2014-03-28 11:45     ` Tamas Blummer
2014-03-28 11:46       ` Mike Hearn
2014-03-28 11:54         ` Tamas Blummer
2014-03-28 12:27           ` Mike Hearn
2014-03-28 12:55             ` Tamas Blummer
2014-03-28 13:00               ` Mike Hearn
2014-03-28 13:09                 ` Tamas Blummer
2014-03-28 11:30 ` Tamas Blummer
2014-03-28 13:18   ` Tamas Blummer
2014-03-28 14:01     ` Gavin Andresen
2014-03-28 14:06       ` Mike Hearn
2014-03-28 14:27       ` Tamas Blummer
2014-03-28 15:23         ` Mike Hearn
2014-03-28 15:26           ` Tamas Blummer
2014-03-28 16:34             ` Mike Hearn
2014-03-28 16:45               ` Tamas Blummer
2014-03-31  9:23 ` Peter Todd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CANEZrP0AwR3WgHfwYWcrC9Z_MHPDwymWXAQwp7D8XZ+o2FsK8g@mail.gmail.com \
    --to=mike@plan99.net \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox