[Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Mike Hearn
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

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Andreas Schildbach
I see the problem. However, I don't see how PaymentDetails can be an answer. None of the fields (other than outputs and network) can be known in advance (at the time of the initial payment). You're probably aiming for an expires field? How would you refund a payment after expiry? Note its not

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Mike Hearn
On Fri, Mar 28, 2014 at 12:25 PM, Andreas Schildbach andr...@schildbach.dewrote: 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,

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Tamas Blummer
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

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Wladimir
On Fri, Mar 28, 2014 at 12:25 PM, Andreas Schildbach andr...@schildbach.dewrote: I see the problem. However, I don't see how PaymentDetails can be an answer. None of the fields (other than outputs and network) can be known in advance (at the time of the initial payment). You're probably

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Tamas Blummer
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

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Mike Hearn
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

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Tamas Blummer
On 28.03.2014, at 12:46, Mike Hearn m...@plan99.net wrote: I don't want to manage a business relationship with every shop I buy something from. That's way too much effort. There can certainly be cases where a more complicated relationship is created by bootstrapping off BIP70, perhaps

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Mike Hearn
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

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Tamas Blummer
On 28.03.2014, at 14:00, Mike Hearn m...@plan99.net wrote: What is too abstract in a contact list ? If the payment comes with a tag like refund the UI could display as such and if it comes with e.g. VAT then that. How is this any different? The tag in this case is the address and the

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Mike Hearn
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

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Tamas Blummer
On 28.03.2014, at 13:27, Mike Hearn m...@plan99.net wrote: It is not more effort than an auto remembered call-in phone number. You delete if you do not care. The difference however is that it would be a clean protocol for repeated payments in both directions for whatever reason, where

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Gavin Andresen
On Fri, Mar 28, 2014 at 9:18 AM, Tamas Blummer ta...@bitsofproof.comwrote: May I ask how the current payment protocol is supposed to handle salaries? It doesn't. walk before you run and all that; lets see what problems we run into with the minimal payment protocol we have now (like refund

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Mike Hearn
So I take it BOPShop won't be supporting BIP70 then? :( On Fri, Mar 28, 2014 at 3:27 PM, Tamas Blummer ta...@bitsofproof.comwrote: I have nothing against incremental development. This will however not pick up until it offers some incremental benefit compared to current payment processor

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Tamas Blummer
On 28.03.2014, at 16:23, Mike Hearn m...@plan99.net wrote: So I take it BOPShop won't be supporting BIP70 then? :( Supporting BIP70 by BitPay or BopShop is a cake since it does no more then they did without it. I am not in opposition but see no reason to be enthusiastic about it. I will once

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Andreas Schildbach
Ok, why don't fix this in the spec for now, by defining a fixed expiry time. In the EU, most products are covered by a 2 years warranty, so it seems appropriate to pick 2.5 years (30 months) -- allowing for some time to ship the product back and forth. On 03/28/2014 12:31 PM, Mike Hearn wrote:

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Mike Hearn
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

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Tamas Blummer
On 28.03.2014, at 17:34, Mike Hearn m...@plan99.net wrote: Supporting BIP70 by BitPay or BopShop is a cake since it does no more then they did without it. I am not in opposition but see no reason to be enthusiastic about it. I will once the spec goes further than what was possible before.

Re: [Bitcoin-development] Tree-chains preliminary summary

2014-03-28 Thread Troy Benjegerdes
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.

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Mike Hearn
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

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Mike Hearn
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

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Tamas Blummer
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

Re: [Bitcoin-development] New BIP32 structure

2014-03-28 Thread slush
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

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Tamas Blummer
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

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Andreas Schildbach
On 03/28/2014 07:19 PM, Mike Hearn wrote: Ok, why don't fix this in the spec for now, by defining a fixed expiry time. In the EU, most products are covered by a 2 years warranty, so it seems appropriate to pick 2.5 years (30 months) -- allowing for some time to ship the product back and

[Bitcoin-development] BIP 70 and OP_RETURN

2014-03-28 Thread Justus Ranvier
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