[Bitcoin-development] BIP 70 refund field

[Bitcoin-development] BIP 70 refund field

[Mike Hearn]

[-- 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 --]

Re: [Bitcoin-development] BIP 70 refund field

[Andreas Schildbach]

I see the problem.

However, I don't see how PaymentDetails can be an answer. None of the
fields (other than outputs and network) can be known in advance (at the
time of the initial payment).

You're probably aiming for an expires field? How would you refund a
payment after expiry? Note its not your choice wether to refund a
payment -- it can be ordered by a court years after the payment happened.

Btw. another problem is that the refund address is currently unprotected.


On 03/28/2014 12:07 PM, Mike Hearn 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
> 

Re: [Bitcoin-development] BIP 70 refund field

[Tamas Blummer]

[-- 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 --]

Re: [Bitcoin-development] BIP 70 refund field

[Mike Hearn]

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

On Fri, Mar 28, 2014 at 12:25 PM, Andreas Schildbach
<andreas@schildbach.de>wrote:

> However, I don't see how PaymentDetails can be an answer. None of the
> fields (other than outputs and network) can be known in advance (at the
> time of the initial payment).
>

You don't need all the fields indeed, but they're mostly optional (except
time). So for the refund you'd fill out:

outputs (same as today)
time
expiry_time

You're probably aiming for an expires field? How would you refund a
> payment after expiry?
>

It'd have to be ad-hoc at that point. OK, you don't get the nice UI that
the refund field provides. Oh well. It should be rare to get refunds very
very late after the purchase.


> Btw. another problem is that the refund address is currently unprotected.
>

Yes indeed as is the rest of the Payment structure. We talked about signing
it with one of the keys that's signing the Bitcoin transaction as well. But
it seems like a bit overkill. Usually it'll be submitted over HTTPS or a
(secured!) Bluetooth channel though so tampering with it should not be
possible.

However this does raise the question of whether a refund should be a full
blown PaymentRequest with optional PKI signing. Normally, I think, a seller
does not know or care about the identity of a buyer for refunds, outside of
their own tracking system.

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

Re: [Bitcoin-development] BIP 70 refund field

[Wladimir]

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

On Fri, Mar 28, 2014 at 12:25 PM, Andreas Schildbach
<andreas@schildbach.de>wrote:

> I see the problem.
>
> However, I don't see how PaymentDetails can be an answer. None of the
> fields (other than outputs and network) can be known in advance (at the
> time of the initial payment).
>
> You're probably aiming for an expires field? How would you refund a
> payment after expiry? Note its not your choice wether to refund a
> payment -- it can be ordered by a court years after the payment happened.
>

Communication between the merchant and buyer would be needed in this case.

I'd say that would be not unreasonable if something is to be refunded after
a year or more. After all, people may have moved, bank accounts changed,
even outside the bitcoin world.

It should probably not be accepted to set a very low expiration time for
the refund address, like <3 months, as it's as bad as not providing a
refund address at all and brings back all the pre-BIP70 confusion.

Wladimir

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

Re: [Bitcoin-development] BIP 70 refund field

[Tamas Blummer]

[-- Attachment #1.1: Type: text/plain, Size: 1862 bytes --]

Yes, you begin to see that the payment protocol, as is has a too narrow scope of a web cart - customer, and does not even fit that.

It is not about payment requests but about business relationships. We need a protocol that deals with that concept instead of individual requests,
so we really get out of the hell of addresses. Business relationships are terminated by the parties at their own and not bey algorithms and timeouts.

Regards,

Tamas Blummer
http://bitsofproof.com

On 28.03.2014, at 12:38, Wladimir <laanwj@gmail.com> wrote:

> 
> On Fri, Mar 28, 2014 at 12:25 PM, Andreas Schildbach <andreas@schildbach.de> wrote:
> I see the problem.
> 
> However, I don't see how PaymentDetails can be an answer. None of the
> fields (other than outputs and network) can be known in advance (at the
> time of the initial payment).
> 
> You're probably aiming for an expires field? How would you refund a
> payment after expiry? Note its not your choice wether to refund a
> payment -- it can be ordered by a court years after the payment happened.
> 
> Communication between the merchant and buyer would be needed in this case.
> 
> I'd say that would be not unreasonable if something is to be refunded after a year or more. After all, people may have moved, bank accounts changed, even outside the bitcoin world.
> 
> It should probably not be accepted to set a very low expiration time for the refund address, like <3 months, as it's as bad as not providing a refund address at all and brings back all the pre-BIP70 confusion.
> 
> Wladimir
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[-- Attachment #1.2: Type: text/html, Size: 5690 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [Bitcoin-development] BIP 70 refund field

[Mike Hearn]

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

I don't want to manage a "business relationship" with every shop I buy
something from. That's way too much effort. There can certainly be cases
where a more complicated relationship is created by bootstrapping off
BIP70, perhaps with an extension, but nailing the ordinary buyer-to-seller
relationship seems like a good scope for BIP70 for now.


On Fri, Mar 28, 2014 at 12:45 PM, Tamas Blummer <tamas@bitsofproof.com>wrote:

> Yes, you begin to see that the payment protocol, as is has a too narrow
> scope of a web cart - customer, and does not even fit that.
>
> It is not about payment requests but about business relationships. We need
> a protocol that deals with that concept instead of individual requests,
> so we really get out of the hell of addresses. Business relationships are
> terminated by the parties at their own and not bey algorithms and timeouts.
>
> Regards,
>
> Tamas Blummer
> http://bitsofproof.com
>
> On 28.03.2014, at 12:38, Wladimir <laanwj@gmail.com> wrote:
>
>
> On Fri, Mar 28, 2014 at 12:25 PM, Andreas Schildbach <
> andreas@schildbach.de> wrote:
>
>> I see the problem.
>>
>> However, I don't see how PaymentDetails can be an answer. None of the
>> fields (other than outputs and network) can be known in advance (at the
>> time of the initial payment).
>>
>> You're probably aiming for an expires field? How would you refund a
>> payment after expiry? Note its not your choice wether to refund a
>> payment -- it can be ordered by a court years after the payment happened.
>>
>
> Communication between the merchant and buyer would be needed in this case.
>
> I'd say that would be not unreasonable if something is to be refunded
> after a year or more. After all, people may have moved, bank accounts
> changed, even outside the bitcoin world.
>
> It should probably not be accepted to set a very low expiration time for
> the refund address, like <3 months, as it's as bad as not providing a
> refund address at all and brings back all the pre-BIP70 confusion.
>
> Wladimir
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

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

Re: [Bitcoin-development] BIP 70 refund field

[Tamas Blummer]

[-- Attachment #1.1: Type: text/plain, Size: 1423 bytes --]


On 28.03.2014, at 12:46, Mike Hearn <mike@plan99.net> wrote:

> I don't want to manage a "business relationship" with every shop I buy something from. That's way too much effort. There can certainly be cases where a more complicated relationship is created by bootstrapping off BIP70, perhaps with an extension, but nailing the ordinary buyer-to-seller relationship seems like a good scope for BIP70 for now.
> 

It is not more effort than an auto remembered call-in phone number. You delete if you do not care. The difference however is that it would be a clean protocol for repeated payments in both directions for whatever reason, where "refund" is and "payment" are not special compared to "1st installment", "overpayed back" or "tip"  or whatever extra charge arises later.


> 
> On Fri, Mar 28, 2014 at 12:45 PM, Tamas Blummer <tamas@bitsofproof.com> wrote:
> Yes, you begin to see that the payment protocol, as is has a too narrow scope of a web cart - customer, and does not even fit that.
> 
> It is not about payment requests but about business relationships. We need a protocol that deals with that concept instead of individual requests,
> so we really get out of the hell of addresses. Business relationships are terminated by the parties at their own and not bey algorithms and timeouts.
> 
> Regards,
> 
> Tamas Blummer
> http://bitsofproof.com
> istinfo/bitcoin-development
> 
> 


[-- Attachment #1.2: Type: text/html, Size: 4405 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [Bitcoin-development] BIP 70 refund field

[Mike Hearn]

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

>
> It is not more effort than an auto remembered call-in phone number. You
> delete if you do not care. The difference however is that it would be a
> clean protocol for repeated payments in both directions for whatever
> reason, where "refund" is and "payment" are not special compared to "1st
> installment", "overpayed back" or "tip"  or whatever extra charge arises
> later.
>

I think that'd be too abstract. The purpose of the refund field is that so
if/when you receive a payment there, the wallet UI can do something
intelligent, like show you in your transactions list that a certain payment
was refunded using language the user will understand. If it's modelled at
the protocol level without that then it makes producing good UI's harder.

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

Re: [Bitcoin-development] BIP 70 refund field

[Tamas Blummer]

[-- Attachment #1.1: Type: text/plain, Size: 966 bytes --]

On 28.03.2014, at 13:27, Mike Hearn <mike@plan99.net> wrote:

> It is not more effort than an auto remembered call-in phone number. You delete if you do not care. The difference however is that it would be a clean protocol for repeated payments in both directions for whatever reason, where "refund" is and "payment" are not special compared to "1st installment", "overpayed back" or "tip"  or whatever extra charge arises later.
> 
> I think that'd be too abstract. The purpose of the refund field is that so if/when you receive a payment there, the wallet UI can do something intelligent, like show you in your transactions list that a certain payment was refunded using language the user will understand. If it's modelled at the protocol level without that then it makes producing good UI's harder.

What is too abstract in a contact list ? If the payment comes with a tag like refund the UI could display as such and if it comes with e.g. VAT then that. 

[-- Attachment #1.2: Type: text/html, Size: 1594 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [Bitcoin-development] BIP 70 refund field

[Mike Hearn]

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

>
> What is too abstract in a contact list ? If the payment comes with a tag
> like refund the UI could display as such and if it comes with e.g. VAT then
> that.
>

How is this any different? The tag in this case is the address and the
payment is being delivered by the block chain (direct submission for
user->merchant is easier than merchant->user) so we can't stuff extra data
anywhere else. Then the UI knows it was a refund payment and not for
anything else.

I don't see the relevance of VAT here.

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

Re: [Bitcoin-development] BIP 70 refund field

[Tamas Blummer]

[-- Attachment #1.1: Type: text/plain, Size: 1353 bytes --]

On 28.03.2014, at 14:00, Mike Hearn <mike@plan99.net> wrote:

> What is too abstract in a contact list ? If the payment comes with a tag like refund the UI could display as such and if it comes with e.g. VAT then that. 
> 
> How is this any different? The tag in this case is the address and the payment is being delivered by the block chain (direct submission for user->merchant is easier than merchant->user) so we can't stuff extra data anywhere else. Then the UI knows it was a refund payment and not for anything else.
> 

The difference is the concept of setting up a channel that allows both parties to create valid addresses of the other by exchanging some kind of master keys. The initial handshake with the protocol would agree on tags of individual address indexes if used. The wallets would have to observe those agreed inidices and evtl. extend range. Payments could go back and forth. Either party might delete the channel information and stop observing keys as soon as he does no longer expect a payment from the other. This would be an explicit operation, like deleting a contact.

> I don't see the relevance of VAT here.

It was an example label. I would not be suprised if with widespread use of payments some government would require VAT collected separately. It is just a guess and has no weight in my prior arguments. 

[-- Attachment #1.2: Type: text/html, Size: 2136 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [Bitcoin-development] BIP 70 refund field

[Tamas Blummer]

[-- Attachment #1.1: Type: text/plain, Size: 2958 bytes --]

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 <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. 
> 
> 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: 8079 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [Bitcoin-development] BIP 70 refund field

[Gavin Andresen]

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

On Fri, Mar 28, 2014 at 9:18 AM, Tamas Blummer <tamas@bitsofproof.com>wrote:

> May I ask how the current payment protocol is supposed to handle salaries?
>

It doesn't.

"walk before you run" and all that; lets see what problems we run into with
the minimal payment protocol we have now (like refund outputs you have to
remember forever) before we create an insurmountable set of problems by
trying to solve everything we can think of all at once.

-- 
--
Gavin Andresen

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

Re: [Bitcoin-development] BIP 70 refund field

[Mike Hearn]

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

Yeah. Though there's actually a proposal for recurring payments from the
KillBill folks. I keep bugging BitPay to review it but it seems they're
lagging behind there, so perhaps we should just move ahead with that
candidate extension.


On Fri, Mar 28, 2014 at 3:01 PM, Gavin Andresen <gavinandresen@gmail.com>wrote:

> On Fri, Mar 28, 2014 at 9:18 AM, Tamas Blummer <tamas@bitsofproof.com>wrote:
>
>> May I ask how the current payment protocol is supposed to handle salaries?
>>
>
> It doesn't.
>
> "walk before you run" and all that; lets see what problems we run into
> with the minimal payment protocol we have now (like refund outputs you have
> to remember forever) before we create an insurmountable set of problems by
> trying to solve everything we can think of all at once.
>
> --
> --
> Gavin Andresen
>

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

Re: [Bitcoin-development] BIP 70 refund field

[Tamas Blummer]

[-- Attachment #1.1: Type: text/plain, Size: 1088 bytes --]

I have nothing against incremental development. This will however not pick up until it offers some incremental benefit compared to current payment processor solutions, 
such as e.g.

1. Symmetrical. One can also offer a payment.
2. Aggregating and Netting. Handle multiple installments and/or net with previous cash flows.
3. More secure. One has a check not only on the payment address (which already has one with https:// in the web shop scenario it is currently able support) but not on the refund.


On 28.03.2014, at 15:01, Gavin Andresen <gavinandresen@gmail.com> wrote:

> On Fri, Mar 28, 2014 at 9:18 AM, Tamas Blummer <tamas@bitsofproof.com> wrote:
> May I ask how the current payment protocol is supposed to handle salaries?
> 
> It doesn't.
> 
> "walk before you run" and all that; lets see what problems we run into with the minimal payment protocol we have now (like refund outputs you have to remember forever) before we create an insurmountable set of problems by trying to solve everything we can think of all at once.
> 
> -- 
> --
> Gavin Andresen


[-- Attachment #1.2: Type: text/html, Size: 1905 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [Bitcoin-development] BIP 70 refund field

[Mike Hearn]

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

So I take it BOPShop won't be supporting BIP70 then? :(


On Fri, Mar 28, 2014 at 3:27 PM, Tamas Blummer <tamas@bitsofproof.com>wrote:

> I have nothing against incremental development. This will however not pick
> up until it offers some incremental benefit compared to current payment
> processor solutions,
> such as e.g.
>
> 1. Symmetrical. One can also offer a payment.
> 2. Aggregating and Netting. Handle multiple installments and/or net with
> previous cash flows.
> 3. More secure. One has a check not only on the payment address (which
> already has one with https:// in the web shop scenario it is currently
> able support) but not on the refund.
>
>
> On 28.03.2014, at 15:01, Gavin Andresen <gavinandresen@gmail.com> wrote:
>
> On Fri, Mar 28, 2014 at 9:18 AM, Tamas Blummer <tamas@bitsofproof.com>wrote:
>
>> May I ask how the current payment protocol is supposed to handle salaries?
>>
>
> It doesn't.
>
> "walk before you run" and all that; lets see what problems we run into
> with the minimal payment protocol we have now (like refund outputs you have
> to remember forever) before we create an insurmountable set of problems by
> trying to solve everything we can think of all at once.
>
> --
> --
> Gavin Andresen
>
>
>

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

Re: [Bitcoin-development] BIP 70 refund field

[Tamas Blummer]

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

On 28.03.2014, at 16:23, Mike Hearn <mike@plan99.net> wrote:
> So I take it BOPShop won't be supporting BIP70 then? :(
> 

Supporting BIP70 by BitPay or BopShop is a cake since it does no more then they did without it.
I am not in opposition but see no reason to be enthusiastic about it. I will once the spec goes
further than what was possible before.

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [Bitcoin-development] BIP 70 refund field

[Mike Hearn]

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

>
> Supporting BIP70 by BitPay or BopShop is a cake since it does no more then
> they did without it.
> I am not in opposition but see no reason to be enthusiastic about it. I
> will once the spec goes
> further than what was possible before.
>

So, if e.g. Trezor ships a firmware update that uses BIP70 to present
signed payment identities on the screen, would you support it then?

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

Re: [Bitcoin-development] BIP 70 refund field

[Tamas Blummer]

[-- Attachment #1.1: Type: text/plain, Size: 594 bytes --]


On 28.03.2014, at 17:34, Mike Hearn <mike@plan99.net> wrote:
> Supporting BIP70 by BitPay or BopShop is a cake since it does no more then they did without it.
> I am not in opposition but see no reason to be enthusiastic about it. I will once the spec goes
> further than what was possible before.
> 
> So, if e.g. Trezor ships a firmware update that uses BIP70 to present signed payment identities on the screen, would you support it then?

Yes that would be neat and I would not want to spoil the show. I wish the established identity could be re-used though to send and much more.

[-- Attachment #1.2: Type: text/html, Size: 1142 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [Bitcoin-development] BIP 70 refund field

[Andreas Schildbach]

Ok, why don't fix this in the spec for now, by defining a fixed expiry
time. In the EU, most products are covered by a 2 years warranty, so it
seems appropriate to pick 2.5 years (30 months) -- allowing for some
time to ship the product back and forth.


On 03/28/2014 12:31 PM, Mike Hearn wrote:
> On Fri, Mar 28, 2014 at 12:25 PM, Andreas Schildbach
> <andreas@schildbach.de <mailto:andreas@schildbach.de>> wrote:
> 
>     However, I don't see how PaymentDetails can be an answer. None of the
>     fields (other than outputs and network) can be known in advance (at the
>     time of the initial payment).
> 
> 
> You don't need all the fields indeed, but they're mostly optional
> (except time). So for the refund you'd fill out:
> 
> outputs (same as today)
> time
> expiry_time
> 
>     You're probably aiming for an expires field? How would you refund a
>     payment after expiry?
> 
> 
> It'd have to be ad-hoc at that point. OK, you don't get the nice UI that
> the refund field provides. Oh well. It should be rare to get refunds
> very very late after the purchase.
>  
> 
>     Btw. another problem is that the refund address is currently
>     unprotected.
> 
> 
> Yes indeed as is the rest of the Payment structure. We talked about
> signing it with one of the keys that's signing the Bitcoin transaction
> as well. But it seems like a bit overkill. Usually it'll be submitted
> over HTTPS or a (secured!) Bluetooth channel though so tampering with it
> should not be possible.
> 
> However this does raise the question of whether a refund should be a
> full blown PaymentRequest with optional PKI signing. Normally, I think,
> a seller does not know or care about the identity of a buyer for
> refunds, outside of their own tracking system.
> 
> 
> ------------------------------------------------------------------------------
> 
> 
> 
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

Re: [Bitcoin-development] BIP 70 refund field

[Mike Hearn]

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

On 28/03/2014 17:59, Andreas Schildbach wrote:
> Ok, why don't fix this in the spec for now, by defining a fixed expiry
> time. In the EU, most products are covered by a 2 years warranty, so it
> seems appropriate to pick 2.5 years (30 months) -- allowing for some
> time to ship the product back and forth.
Yeah I was thinking something like that on the walk home. But 2 years is
a long time. Do we have enough RAM for that? Plus warranties usually
result in the defective goods being replaced rather than a monetary
refund, right?

But adjusting the spec so there's a fixed time limit, and allowing a
future version of the protocol to make it configurable, does indeed feel
like the right way to go.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5971 bytes --]

Re: [Bitcoin-development] BIP 70 refund field

[Andreas Schildbach]

On 03/28/2014 07:19 PM, Mike Hearn wrote:

>> Ok, why don't fix this in the spec for now, by defining a fixed expiry
>> time. In the EU, most products are covered by a 2 years warranty, so it
>> seems appropriate to pick 2.5 years (30 months) -- allowing for some
>> time to ship the product back and forth.
>
> Yeah I was thinking something like that on the walk home. But 2 years is
> a long time. Do we have enough RAM for that?

It depends on usage stats, script size, etc...

> Plus warranties usually
> result in the defective goods being replaced rather than a monetary
> refund, right?

Usually yes. The next smaller "unit of time" in Germany would be two
weeks, the so-called "Fernabsatzgesetz". It allows you to send back
mail-orders and usually you want the money back. Don't know if that made
it into EU law or how it applies to other countries.

Re: [Bitcoin-development] BIP 70 refund field

[Roy Badami]

On Fri, Mar 28, 2014 at 09:56:57PM +0100, Andreas Schildbach wrote:
> On 03/28/2014 07:19 PM, Mike Hearn wrote:
> 
> >> Ok, why don't fix this in the spec for now, by defining a fixed expiry
> >> time. In the EU, most products are covered by a 2 years warranty, so it
> >> seems appropriate to pick 2.5 years (30 months) -- allowing for some
> >> time to ship the product back and forth.
> >
> > Yeah I was thinking something like that on the walk home. But 2 years is
> > a long time. Do we have enough RAM for that?
> 
> It depends on usage stats, script size, etc...
> 
> > Plus warranties usually
> > result in the defective goods being replaced rather than a monetary
> > refund, right?
> 
> Usually yes. The next smaller "unit of time" in Germany would be two
> weeks, the so-called "Fernabsatzgesetz". It allows you to send back
> mail-orders and usually you want the money back. Don't know if that made
> it into EU law or how it applies to other countries.

It's EU law, but the Distance Selling Directive only says "at least
seven days", so the exact period probably varies by country (in the UK
it is 7 days).

But the clock only starts ticking when you receive the goods, and the
Distance Selling Directive allows the supplier 30 days "to execute the
order" (I *think* the 30 days always has to include shipping, because
for consumer contracts title doesn't pass until the goods are
delivered, so the order wouldn't be considered complete until then).

So I think latest possible deadline for returning the goods for refund
could be up to 30 days to execute the order plus "at least 7 days"
(with some countries allowing more).  Plus, conceivably, shipping
time, if some member states have chosen to interpret the 30 day
execution differently.

So I think this adds up to "a couple of months, give or take".  In
practice, though, even a couple of months is a bit on the short time.
What if the goods are delayed.  How many people have had miner orders
outstanding for the best part of a year?

roy

Re: [Bitcoin-development] BIP 70 refund field

[Mike Hearn]

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

So how about we say two months? That way it's easy for merchants to comply
with the EU DSD and we keep RAM usage in check until we come up with a more
sophisticated refund scheme.

There's another issue with BIP 70 and refunds that I noticed. The
PaymentRequest doesn't specify whether refunds are possible. So wallets
have to either never submit refund data, or always submit it even if it
makes no sense. Because setting things up to get refunds has a non-zero
cost for the sender, it'd help if we could optimise it away for merchants
that simply refuse to issue refunds for whatever reason.



On Sat, Mar 29, 2014 at 10:27 AM, Roy Badami <roy@gnomon.org.uk> wrote:

> On Fri, Mar 28, 2014 at 09:56:57PM +0100, Andreas Schildbach wrote:
> > On 03/28/2014 07:19 PM, Mike Hearn wrote:
> >
> > >> Ok, why don't fix this in the spec for now, by defining a fixed expiry
> > >> time. In the EU, most products are covered by a 2 years warranty, so
> it
> > >> seems appropriate to pick 2.5 years (30 months) -- allowing for some
> > >> time to ship the product back and forth.
> > >
> > > Yeah I was thinking something like that on the walk home. But 2 years
> is
> > > a long time. Do we have enough RAM for that?
> >
> > It depends on usage stats, script size, etc...
> >
> > > Plus warranties usually
> > > result in the defective goods being replaced rather than a monetary
> > > refund, right?
> >
> > Usually yes. The next smaller "unit of time" in Germany would be two
> > weeks, the so-called "Fernabsatzgesetz". It allows you to send back
> > mail-orders and usually you want the money back. Don't know if that made
> > it into EU law or how it applies to other countries.
>
> It's EU law, but the Distance Selling Directive only says "at least
> seven days", so the exact period probably varies by country (in the UK
> it is 7 days).
>
> But the clock only starts ticking when you receive the goods, and the
> Distance Selling Directive allows the supplier 30 days "to execute the
> order" (I *think* the 30 days always has to include shipping, because
> for consumer contracts title doesn't pass until the goods are
> delivered, so the order wouldn't be considered complete until then).
>
> So I think latest possible deadline for returning the goods for refund
> could be up to 30 days to execute the order plus "at least 7 days"
> (with some countries allowing more).  Plus, conceivably, shipping
> time, if some member states have chosen to interpret the 30 day
> execution differently.
>
> So I think this adds up to "a couple of months, give or take".  In
> practice, though, even a couple of months is a bit on the short time.
> What if the goods are delayed.  How many people have had miner orders
> outstanding for the best part of a year?
>
> roy
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

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

Re: [Bitcoin-development] BIP 70 refund field

[Andreas Schildbach]

I'd prefer 3 months to 2 just because a quarter of year is a more common
timespan.

But of course its just paint shedding, so 2 sounds good for me too (-:


On 03/29/2014 02:29 PM, Mike Hearn wrote:
> So how about we say two months? That way it's easy for merchants to
> comply with the EU DSD and we keep RAM usage in check until we come up
> with a more sophisticated refund scheme.
> 
> There's another issue with BIP 70 and refunds that I noticed. The
> PaymentRequest doesn't specify whether refunds are possible. So wallets
> have to either never submit refund data, or always submit it even if it
> makes no sense. Because setting things up to get refunds has a non-zero
> cost for the sender, it'd help if we could optimise it away for
> merchants that simply refuse to issue refunds for whatever reason.
> 
> 
> 
> On Sat, Mar 29, 2014 at 10:27 AM, Roy Badami <roy@gnomon.org.uk
> <mailto:roy@gnomon.org.uk>> wrote:
> 
>     On Fri, Mar 28, 2014 at 09:56:57PM +0100, Andreas Schildbach wrote:
>     > On 03/28/2014 07:19 PM, Mike Hearn wrote:
>     >
>     > >> Ok, why don't fix this in the spec for now, by defining a fixed
>     expiry
>     > >> time. In the EU, most products are covered by a 2 years
>     warranty, so it
>     > >> seems appropriate to pick 2.5 years (30 months) -- allowing for
>     some
>     > >> time to ship the product back and forth.
>     > >
>     > > Yeah I was thinking something like that on the walk home. But 2
>     years is
>     > > a long time. Do we have enough RAM for that?
>     >
>     > It depends on usage stats, script size, etc...
>     >
>     > > Plus warranties usually
>     > > result in the defective goods being replaced rather than a monetary
>     > > refund, right?
>     >
>     > Usually yes. The next smaller "unit of time" in Germany would be two
>     > weeks, the so-called "Fernabsatzgesetz". It allows you to send back
>     > mail-orders and usually you want the money back. Don't know if
>     that made
>     > it into EU law or how it applies to other countries.
> 
>     It's EU law, but the Distance Selling Directive only says "at least
>     seven days", so the exact period probably varies by country (in the UK
>     it is 7 days).
> 
>     But the clock only starts ticking when you receive the goods, and the
>     Distance Selling Directive allows the supplier 30 days "to execute the
>     order" (I *think* the 30 days always has to include shipping, because
>     for consumer contracts title doesn't pass until the goods are
>     delivered, so the order wouldn't be considered complete until then).
> 
>     So I think latest possible deadline for returning the goods for refund
>     could be up to 30 days to execute the order plus "at least 7 days"
>     (with some countries allowing more).  Plus, conceivably, shipping
>     time, if some member states have chosen to interpret the 30 day
>     execution differently.
> 
>     So I think this adds up to "a couple of months, give or take".  In
>     practice, though, even a couple of months is a bit on the short time.
>     What if the goods are delayed.  How many people have had miner orders
>     outstanding for the best part of a year?
> 
>     roy
> 
> 
>     ------------------------------------------------------------------------------
>     _______________________________________________
>     Bitcoin-development mailing list
>     Bitcoin-development@lists.sourceforge.net
>     <mailto:Bitcoin-development@lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> 
> 
> 
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

Re: [Bitcoin-development] BIP 70 refund field

[Peter Todd]

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

On Fri, Mar 28, 2014 at 12:07:04PM +0100, Mike Hearn wrote:
> 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.

One of the main goals of steath addresses is actually scalability. In
particular in the refund address case you would use stealth addresses
with a per-order UUID so that refunds can be detected cheaply by just
scanning for payments to your (single) stealth address, then when those
payments are detected, check the UUID against a on-disk database. A
64-bit "UUID" is probably fine, although unfortunately with OP_RETURN
quite unexpectedly dropped to 40 bytes the standard needs to change;
might have to compromise on privacy and re-use a txin pubkey to make
things fit.

-- 
'peter'[:-1]@petertodd.org
0000000000000000f4f5ba334791a4102917e4d3f22f6ad7f2c4f15d97307fe2

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 665 bytes --]