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
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 an
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 an
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.
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
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
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 F
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:
>
>
> 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
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
> 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. Le
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
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.
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
r
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
>
> 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
> i
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 bei
>
> 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 submissi
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 exten
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
relationsh
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
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 exp
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
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
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 you
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 device
26 matches
Mail list logo
