From: Tamas Blummer <tamas@bitsofproof•com>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] BIP 70 refund field
Date: Fri, 28 Mar 2014 12:30:39 +0100 [thread overview]
Message-ID: <612FFAAD-14FF-4261-927D-BD2E0F287257@bitsofproof.com> (raw)
In-Reply-To: <CANEZrP0AwR3WgHfwYWcrC9Z_MHPDwymWXAQwp7D8XZ+o2FsK8g@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2549 bytes --]
Instead of a payment request and refund, businesses would actually need a payment channel, that once established allows for multiple payments back and forth between counterparties.
One might have a number of open channels until the business relationship is assumed. The customer might decide to close the channel explicitelly once he does no longer expect a payment.
Regards,
Tamás Blummer
http://bitsofproof.com
On 28.03.2014, at 12:07, Mike Hearn <mike@plan99•net> 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
[-- Attachment #1.2: Type: text/html, Size: 5738 bytes --]
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
next prev parent reply other threads:[~2014-03-28 11:30 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-28 11:07 Mike Hearn
2014-03-28 11:25 ` 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 [this message]
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=612FFAAD-14FF-4261-927D-BD2E0F287257@bitsofproof.com \
--to=tamas@bitsofproof$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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