[Bitcoin-development] BIP 70 and OP_RETURN
The description of the Output message states that the payment request can specify any standard TxOut script, and that OP_RETURN is a standard transaction type that would imply the ability to specify OP_RETURN outputs in BIP 70 payment requests. If the creator of a payment request wanted the sender to include a small amount of data as an OP_RETURN output, how would they specify this? -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k 0x1B438BF4.asc Description: application/pgp-keys signature.asc Description: OpenPGP 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
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
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 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 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 wrote: > On Fri, Mar 28, 2014 at 9:18 AM, Tamas Blummer 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] New BIP32 structure
I agree that 'version' field of bip32 is not necessary and xpriv/xpub should be enough for all cases; there's actually no need to use different BIP32 roots for different altcoins. I'm happily using one xpub for Bitcoin/Testnet/Litecoin at once, and by having the "cointype" distinction in the bip32 path itself, I'm sure that I don't reuse the same pubkey across blockchains which may be a privacy issue otherwise. Marek On Thu, Mar 27, 2014 at 5:28 PM, Pieter Wuille wrote: > On Thu, Mar 27, 2014 at 5:21 PM, Pavol Rusnak wrote: > > Cointype in path is for separation purposes, not for identification. > > I don't understand what that gains you. > > -- > Pieter > > > -- > ___ > 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
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 wrote: > On Fri, Mar 28, 2014 at 9:18 AM, Tamas Blummer 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 > -- ___ 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 > 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 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] Tree-chains preliminary summary
> Anyway the particular situation in which a single entity controls 40% > of the hashing power should be rare. That's potentially dangerous for > bitcoin and although changing the hashing algorithm would be painful > and risky, I would be terribly scared of that happening if I was that > entity. Letting my percentage of hash rate dilute as others grow would > definitely be part of my plan. I think *your* plan is an ecologically and socially rational plan. My observations of irrational responses on this list lead me to believe there is a single entity (which may be a cartel) which *effectively* controls between 30% and 50% of the sha-256 hashing power and is quite terrified of any alternative, and attempts to purchase, consume, or eliminate any entities that might dilute it's controlled hash rate or pose a risk of switching to a new algorithm. We must have a system in which 1 to 10% of the hashrate can provide a reasonable check-and-balance and competitive pressure to 90% of the hash rate, or it's going to be fundamentally unstable, and we will just re-create 'to big to fail' all over again. > Although this is again completely orthogonal to the merged mining or > not discussion, hashing algorithms are often mixed in the discussions > against merged mining. If you had to introduce that hashing algorithm > hardfork change you will probably chose something with similar > properties than those of SHA256, like being easy to implement > specialized hardware for it. You could even chose a memory-hard > algorithm if you want to promote ASIC production centralization, but > you can't chose an "anti-ASIC" algorithm because those don't exist. > It is well known that any information machine that can be built with > software can also be built with specialized hardware and viceversa. > Sadly that kind of fallacy is often used to justify the ecological > crime that starting a new chain with no plans of doing merged mining > represents. You speak of ecological crime without proposing any mechanism in which the ecologically correct thing is also the economically rational thing. If I could get real-time MISO market pricing for wind energy, I could do this http://grid.coop/smartgridcmp-long.png and run a mining farm on my farm. I would like to propose we collaborate on developing secure mechanism to audit energy sources for miners on a new chain called 'Ecocoin' in which the block reward is proportional to how much energy the owner of the newly generated block reward personally harvested from renewable sources. The reward curve will have to be calibrated and adjusted to minimize the over all costs and fraud risk of auditing the energy input sources. -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- ___ 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 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
So I take it BOPShop won't be supporting BIP70 then? :( On Fri, Mar 28, 2014 at 3:27 PM, Tamas Blummer 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 wrote: > > On Fri, Mar 28, 2014 at 9:18 AM, Tamas Blummer 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 > > > -- ___ 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 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 -- ___ 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 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
> > 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 14:00, Mike Hearn 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
> > 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 12:46, Mike Hearn 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 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
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 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 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
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 wrote: > > On Fri, Mar 28, 2014 at 12:25 PM, Andreas Schildbach > 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
On Fri, Mar 28, 2014 at 12:25 PM, Andreas Schildbach 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
Re: [Bitcoin-development] BIP 70 refund field
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 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
On Fri, Mar 28, 2014 at 12:25 PM, Andreas Schildbach 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
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
[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
