Re: [Bitcoin-development] BIP 70 refund field
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 f4f5ba334791a4102917e4d3f22f6ad7f2c4f15d97307fe2 signature.asc Description: Digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
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 r...@gnomon.org.uk mailto:r...@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 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
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
[Bitcoin-development] BIP 70 refund field
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
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 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
On Fri, Mar 28, 2014 at 12:25 PM, Andreas Schildbach andr...@schildbach.dewrote: 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
Re: [Bitcoin-development] BIP 70 refund field
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 laa...@gmail.com wrote: On Fri, Mar 28, 2014 at 12:25 PM, Andreas Schildbach andr...@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 signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
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 ta...@bitsofproof.comwrote: 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 laa...@gmail.com wrote: On Fri, Mar 28, 2014 at 12:25 PM, Andreas Schildbach andr...@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 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
On 28.03.2014, at 12:46, Mike Hearn m...@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 ta...@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 signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
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. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
On 28.03.2014, at 14:00, Mike Hearn m...@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. signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
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. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
On 28.03.2014, at 13:27, Mike Hearn m...@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. signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
On Fri, Mar 28, 2014 at 9:18 AM, Tamas Blummer ta...@bitsofproof.comwrote: 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 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
So I take it BOPShop won't be supporting BIP70 then? :( On Fri, Mar 28, 2014 at 3:27 PM, Tamas Blummer ta...@bitsofproof.comwrote: 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 gavinandre...@gmail.com wrote: On Fri, Mar 28, 2014 at 9:18 AM, Tamas Blummer ta...@bitsofproof.comwrote: 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 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
On 28.03.2014, at 16:23, Mike Hearn m...@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. signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
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 andr...@schildbach.de mailto:andr...@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 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
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? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
On 28.03.2014, at 17:34, Mike Hearn m...@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. signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
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 gavinandre...@gmail.comwrote: On Fri, Mar 28, 2014 at 9:18 AM, Tamas Blummer ta...@bitsofproof.comwrote: 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 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
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. smime.p7s Description: S/MIME Cryptographic Signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
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 ta...@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 m...@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 signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
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 gavinandre...@gmail.com wrote: On Fri, Mar 28, 2014 at 9:18 AM, Tamas Blummer ta...@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 signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
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. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
