* [Bitcoin-development] BIP 70 refund field
@ 2014-03-28 11:07 Mike Hearn
2014-03-28 11:25 ` Andreas Schildbach
` (2 more replies)
0 siblings, 3 replies; 27+ messages in thread
From: Mike Hearn @ 2014-03-28 11:07 UTC (permalink / raw)
To: Bitcoin Dev
[-- 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 --]
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: [Bitcoin-development] BIP 70 refund field 2014-03-28 11:07 [Bitcoin-development] BIP 70 refund field Mike Hearn @ 2014-03-28 11:25 ` Andreas Schildbach 2014-03-28 11:31 ` Mike Hearn 2014-03-28 11:38 ` Wladimir 2014-03-28 11:30 ` Tamas Blummer 2014-03-31 9:23 ` Peter Todd 2 siblings, 2 replies; 27+ messages in thread From: Andreas Schildbach @ 2014-03-28 11:25 UTC (permalink / raw) To: bitcoin-development 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 > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] BIP 70 refund field 2014-03-28 11:25 ` Andreas Schildbach @ 2014-03-28 11:31 ` Mike Hearn 2014-03-28 16:59 ` Andreas Schildbach 2014-03-28 11:38 ` Wladimir 1 sibling, 1 reply; 27+ messages in thread From: Mike Hearn @ 2014-03-28 11:31 UTC (permalink / raw) To: Andreas Schildbach; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] BIP 70 refund field 2014-03-28 11:31 ` Mike Hearn @ 2014-03-28 16:59 ` Andreas Schildbach 2014-03-28 18:19 ` Mike Hearn 0 siblings, 1 reply; 27+ messages in thread From: Andreas Schildbach @ 2014-03-28 16:59 UTC (permalink / raw) To: bitcoin-development 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 > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] BIP 70 refund field 2014-03-28 16:59 ` Andreas Schildbach @ 2014-03-28 18:19 ` Mike Hearn 2014-03-28 20:56 ` Andreas Schildbach 0 siblings, 1 reply; 27+ messages in thread From: Mike Hearn @ 2014-03-28 18:19 UTC (permalink / raw) To: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] BIP 70 refund field 2014-03-28 18:19 ` Mike Hearn @ 2014-03-28 20:56 ` Andreas Schildbach 2014-03-29 9:27 ` Roy Badami 0 siblings, 1 reply; 27+ messages in thread From: Andreas Schildbach @ 2014-03-28 20:56 UTC (permalink / raw) To: bitcoin-development 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] BIP 70 refund field 2014-03-28 20:56 ` Andreas Schildbach @ 2014-03-29 9:27 ` Roy Badami 2014-03-29 13:29 ` Mike Hearn 0 siblings, 1 reply; 27+ messages in thread From: Roy Badami @ 2014-03-29 9:27 UTC (permalink / raw) To: Andreas Schildbach; +Cc: bitcoin-development 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] BIP 70 refund field 2014-03-29 9:27 ` Roy Badami @ 2014-03-29 13:29 ` Mike Hearn 2014-03-30 17:21 ` Andreas Schildbach 0 siblings, 1 reply; 27+ messages in thread From: Mike Hearn @ 2014-03-29 13:29 UTC (permalink / raw) To: Roy Badami; +Cc: Bitcoin Dev, Andreas Schildbach [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] BIP 70 refund field 2014-03-29 13:29 ` Mike Hearn @ 2014-03-30 17:21 ` Andreas Schildbach 0 siblings, 0 replies; 27+ messages in thread From: Andreas Schildbach @ 2014-03-30 17:21 UTC (permalink / raw) To: bitcoin-development 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 > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] BIP 70 refund field 2014-03-28 11:25 ` Andreas Schildbach 2014-03-28 11:31 ` Mike Hearn @ 2014-03-28 11:38 ` Wladimir 2014-03-28 11:45 ` Tamas Blummer 1 sibling, 1 reply; 27+ messages in thread From: Wladimir @ 2014-03-28 11:38 UTC (permalink / raw) To: Andreas Schildbach; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] BIP 70 refund field 2014-03-28 11:38 ` Wladimir @ 2014-03-28 11:45 ` Tamas Blummer 2014-03-28 11:46 ` Mike Hearn 0 siblings, 1 reply; 27+ messages in thread From: Tamas Blummer @ 2014-03-28 11:45 UTC (permalink / raw) To: Wladimir; +Cc: Bitcoin Dev, Andreas Schildbach [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] BIP 70 refund field 2014-03-28 11:45 ` Tamas Blummer @ 2014-03-28 11:46 ` Mike Hearn 2014-03-28 11:54 ` Tamas Blummer 0 siblings, 1 reply; 27+ messages in thread From: Mike Hearn @ 2014-03-28 11:46 UTC (permalink / raw) To: Tamas Blummer; +Cc: Bitcoin Dev, Andreas Schildbach [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] BIP 70 refund field 2014-03-28 11:46 ` Mike Hearn @ 2014-03-28 11:54 ` Tamas Blummer 2014-03-28 12:27 ` Mike Hearn 0 siblings, 1 reply; 27+ messages in thread From: Tamas Blummer @ 2014-03-28 11:54 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev, Andreas Schildbach [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] BIP 70 refund field 2014-03-28 11:54 ` Tamas Blummer @ 2014-03-28 12:27 ` Mike Hearn 2014-03-28 12:55 ` Tamas Blummer 0 siblings, 1 reply; 27+ messages in thread From: Mike Hearn @ 2014-03-28 12:27 UTC (permalink / raw) To: Tamas Blummer; +Cc: Bitcoin Dev, Andreas Schildbach [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] BIP 70 refund field 2014-03-28 12:27 ` Mike Hearn @ 2014-03-28 12:55 ` Tamas Blummer 2014-03-28 13:00 ` Mike Hearn 0 siblings, 1 reply; 27+ messages in thread From: Tamas Blummer @ 2014-03-28 12:55 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev, Andreas Schildbach [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] BIP 70 refund field 2014-03-28 12:55 ` Tamas Blummer @ 2014-03-28 13:00 ` Mike Hearn 2014-03-28 13:09 ` Tamas Blummer 0 siblings, 1 reply; 27+ messages in thread From: Mike Hearn @ 2014-03-28 13:00 UTC (permalink / raw) To: Tamas Blummer; +Cc: Bitcoin Dev, Andreas Schildbach [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] BIP 70 refund field 2014-03-28 13:00 ` Mike Hearn @ 2014-03-28 13:09 ` Tamas Blummer 0 siblings, 0 replies; 27+ messages in thread From: Tamas Blummer @ 2014-03-28 13:09 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev, Andreas Schildbach [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] BIP 70 refund field 2014-03-28 11:07 [Bitcoin-development] BIP 70 refund field Mike Hearn 2014-03-28 11:25 ` Andreas Schildbach @ 2014-03-28 11:30 ` Tamas Blummer 2014-03-28 13:18 ` Tamas Blummer 2014-03-31 9:23 ` Peter Todd 2 siblings, 1 reply; 27+ messages in thread From: Tamas Blummer @ 2014-03-28 11:30 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] BIP 70 refund field 2014-03-28 11:30 ` Tamas Blummer @ 2014-03-28 13:18 ` Tamas Blummer 2014-03-28 14:01 ` Gavin Andresen 0 siblings, 1 reply; 27+ messages in thread From: Tamas Blummer @ 2014-03-28 13:18 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] BIP 70 refund field 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 0 siblings, 2 replies; 27+ messages in thread From: Gavin Andresen @ 2014-03-28 14:01 UTC (permalink / raw) To: Tamas Blummer; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] BIP 70 refund field 2014-03-28 14:01 ` Gavin Andresen @ 2014-03-28 14:06 ` Mike Hearn 2014-03-28 14:27 ` Tamas Blummer 1 sibling, 0 replies; 27+ messages in thread From: Mike Hearn @ 2014-03-28 14:06 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] BIP 70 refund field 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 1 sibling, 1 reply; 27+ messages in thread From: Tamas Blummer @ 2014-03-28 14:27 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] BIP 70 refund field 2014-03-28 14:27 ` Tamas Blummer @ 2014-03-28 15:23 ` Mike Hearn 2014-03-28 15:26 ` Tamas Blummer 0 siblings, 1 reply; 27+ messages in thread From: Mike Hearn @ 2014-03-28 15:23 UTC (permalink / raw) To: Tamas Blummer; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] BIP 70 refund field 2014-03-28 15:23 ` Mike Hearn @ 2014-03-28 15:26 ` Tamas Blummer 2014-03-28 16:34 ` Mike Hearn 0 siblings, 1 reply; 27+ messages in thread From: Tamas Blummer @ 2014-03-28 15:26 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] BIP 70 refund field 2014-03-28 15:26 ` Tamas Blummer @ 2014-03-28 16:34 ` Mike Hearn 2014-03-28 16:45 ` Tamas Blummer 0 siblings, 1 reply; 27+ messages in thread From: Mike Hearn @ 2014-03-28 16:34 UTC (permalink / raw) To: Tamas Blummer; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] BIP 70 refund field 2014-03-28 16:34 ` Mike Hearn @ 2014-03-28 16:45 ` Tamas Blummer 0 siblings, 0 replies; 27+ messages in thread From: Tamas Blummer @ 2014-03-28 16:45 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] BIP 70 refund field 2014-03-28 11:07 [Bitcoin-development] BIP 70 refund field Mike Hearn 2014-03-28 11:25 ` Andreas Schildbach 2014-03-28 11:30 ` Tamas Blummer @ 2014-03-31 9:23 ` Peter Todd 2 siblings, 0 replies; 27+ messages in thread From: Peter Todd @ 2014-03-31 9:23 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2014-03-31 9:23 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-03-28 11:07 [Bitcoin-development] BIP 70 refund field 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 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox