Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WTWfs-0000Jp-Qd for bitcoin-development@lists.sourceforge.net; Fri, 28 Mar 2014 13:18:20 +0000 X-ACL-Warn: Received: from wp059.webpack.hosteurope.de ([80.237.132.66]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1WTWfq-0006Cu-B9 for bitcoin-development@lists.sourceforge.net; Fri, 28 Mar 2014 13:18:20 +0000 Received: from [37.143.74.116] (helo=[192.168.2.2]); authenticated by wp059.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1WTWfj-0005bQ-IA; Fri, 28 Mar 2014 14:18:11 +0100 Content-Type: multipart/signed; boundary="Apple-Mail=_B4CEEEA7-9179-46E3-91B8-E37893293273"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Tamas Blummer In-Reply-To: <612FFAAD-14FF-4261-927D-BD2E0F287257@bitsofproof.com> Date: Fri, 28 Mar 2014 14:18:10 +0100 Message-Id: References: <612FFAAD-14FF-4261-927D-BD2E0F287257@bitsofproof.com> To: Mike Hearn X-Mailer: Apple Mail (2.1510) X-bounce-key: webpack.hosteurope.de; tamas@bitsofproof.com; 1396012698; e7308740; X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1WTWfq-0006Cu-B9 Cc: Bitcoin Dev Subject: Re: [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 13:18:21 -0000 --Apple-Mail=_B4CEEEA7-9179-46E3-91B8-E37893293273 Content-Type: multipart/alternative; boundary="Apple-Mail=_AFDD57A5-2509-47EB-A846-8FD8FB36ABE5" --Apple-Mail=_AFDD57A5-2509-47EB-A846-8FD8FB36ABE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 May I ask how the current payment protocol is supposed to handle = salaries? I hope you do not assume the employee creates a payment = request, since he does not even calculate the amount. There you go where a channel I described is = definitelly needed. Tamas Blummer http://bitsofproof.com On 28.03.2014, at 12:30, Tamas Blummer wrote: > 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. >=20 > 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.=20 >=20 > Regards, >=20 > Tam=E1s Blummer > http://bitsofproof.com >=20 > On 28.03.2014, at 12:07, Mike Hearn wrote: >=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >>=20 >> = --------------------------------------------------------------------------= ---- >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >=20 --Apple-Mail=_AFDD57A5-2509-47EB-A846-8FD8FB36ABE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 May I = ask how the current payment protocol is supposed to handle salaries? I = hope you do not assume the employee creates a payment request, since he = does not
even calculate the amount. There you go where a channel I = described is definitelly needed.
On 28.03.2014, at 12:30, Tamas Blummer <tamas@bitsofproof.com> = wrote:

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. 


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-develop= ment mailing list
Bitcoin-developm= ent@lists.sourceforge.net
= https://lists.sourceforge.net/lists/listinfo/bitcoin-development


= --Apple-Mail=_AFDD57A5-2509-47EB-A846-8FD8FB36ABE5-- --Apple-Mail=_B4CEEEA7-9179-46E3-91B8-E37893293273 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJTNXaTAAoJEPZykcUXcTkcmn8H/RkR4nnfteNlFoy1+lX2VDIw KudvgzRrSgZkXgi2XllnuioG5n+Jz8B5V0HIvvnSN2J3v/m8dO6etQBvHP2uvDR1 lFAlaAYmpFk20WvqexdpPIaDnX0QU5Dc2vlVaTU1k1V934h3pxxQrw1VLqLUDQW+ V6q2fDBAzSeFfYSvCv3hKxNZDvMA8LPu4CmqtGwbK89/g2CUadRQ8V3Gr/LlsvlB JorJ1T/I6LmHDc8EDP6Vea6uG1V2AAe8mLCY4Du3qgJpbkdsAfFQsOHFTxlvvG4z OC85V5CealoUbnvNw5tL6BRNEbJ+tHG0fBmpJ0/HcXC5R5NOf/cb9eS1dgZGh5o= =nbQH -----END PGP SIGNATURE----- --Apple-Mail=_B4CEEEA7-9179-46E3-91B8-E37893293273--