[Bitcoin-development] BIP70: PaymentACK semantics

[Bitcoin-development] BIP70: PaymentACK semantics

[Andreas Schildbach]

The BIP70 is very brief on what a PaymentACK is supposed to mean. Quote:

"it [PaymentACK] is sent from the merchant's server to the bitcoin
wallet in response to a Payment message"

Does it simply mean we received a syntactically correct Payment message?
Does it mean the Payment is valid?
Does it mean the Payment is valid and confirmed?
How long can we delay the ack until all conditions for payment are met?
I assume its not a good idea to keep the HTTP (or Bluetooth, for that
matter) connection open for an hour while waiting for a blockchain
confirmation.

Re: [Bitcoin-development] BIP70: PaymentACK semantics

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]

On Sun, Jan 26, 2014 at 4:56 PM, Andreas Schildbach
<andreas@schildbach.de>wrote:

> The BIP70 is very brief on what a PaymentACK is supposed to mean. Quote:
>
> "it [PaymentACK] is sent from the merchant's server to the bitcoin
> wallet in response to a Payment message"
>
> Does it simply mean we received a syntactically correct Payment message?
>
Does it mean the Payment is valid?
> Does it mean the Payment is valid and confirmed?
> How long can we delay the ack until all conditions for payment are met?
> I assume its not a good idea to keep the HTTP (or Bluetooth, for that
> matter) connection open for an hour while waiting for a blockchain
> confirmation.
>

The purpose of PaymentACK is to give the customer reassurance that their
payment request has been received and will be processed (or not).

If it is syntactically incorrect or invalid in a way that the payment
processor can detect right away then a PaymentACK with a message saying
that there is a problem should be the response.

Waiting until confirmed is definitely not the right thing to do, but
waiting a few seconds to detect a 0-confirmation double-spend attempt
before sending back an ACK is fine.  The BIP is intentionally vague on how
long it might take to get an ACK, but, again, the intent is to give the
customer reassurance that their payment was received and is being
processed, whatever "processed" means (order sent to shipping for
fulfillment, or awaiting 11 confirmations, or "your burger is paid for you
can leave the restaurant and we won't chase after you").


--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 2161 bytes --]

Re: [Bitcoin-development] BIP70: PaymentACK semantics

[Andreas Schildbach]

On 01/27/2014 03:54 PM, Gavin Andresen wrote:

> The purpose of PaymentACK is to give the customer reassurance that their
> payment request has been received and will be processed (or not).
> 
> If it is syntactically incorrect or invalid in a way that the payment
> processor can detect right away then a PaymentACK with a message saying
> that there is a problem should be the response.

Thanks for the clarification. So I am *always* supposed to reply with an
ack. I was assuming that if I actually send a nack, I would just close
the connection without sending an ack.

Maybe that should be mentioned in the spec explicitly. I must admit that
I think the name of the message is misleading -- PaymentResponse would
make this clearer.

Re: [Bitcoin-development] BIP70: PaymentACK semantics

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 225 bytes --]

At the moment there's no way to distinguish between a failed / rejected
submission and a successful one beyond the freeform memo field, right? It'd
be good if we had an error code field as well, perhaps for a future version.

[-- Attachment #2: Type: text/html, Size: 254 bytes --]

Re: [Bitcoin-development] BIP70: PaymentACK semantics

[Kevin Greene]

[-- Attachment #1: Type: text/plain, Size: 1081 bytes --]

+1 for an error field.

Should the wallet broadcast the transaction to the bitcoin network when it
receives an ACK, or always assume that the merchant server will do that?


On Mon, Jan 27, 2014 at 7:52 AM, Mike Hearn <mike@plan99.net> wrote:

> At the moment there's no way to distinguish between a failed / rejected
> submission and a successful one beyond the freeform memo field, right? It'd
> be good if we had an error code field as well, perhaps for a future version.
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 1884 bytes --]

Re: [Bitcoin-development] BIP70: PaymentACK semantics

[Pieter Wuille]

On Mon, Jan 27, 2014 at 11:03 PM, Kevin Greene <kgreenek@gmail.com> wrote:
> +1 for an error field.

Agree, I think we need a way for client applications to interpret the response.

> Should the wallet broadcast the transaction to the bitcoin network when it
> receives an ACK, or always assume that the merchant server will do that?

In my opinion, that should be the primary meaning of receiving an ACK:
acknowledgement that the receiver takes responsibility for getting the
transaction confirmed (to the extent possible, of course).


-- 
Pieter

Re: [Bitcoin-development] BIP70: PaymentACK semantics

[Kevin Greene]

[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]

>> Should the wallet broadcast the transaction to the bitcoin network when
it
>> receives an ACK, or always assume that the merchant server will do that?
>
> In my opinion, that should be the primary meaning of receiving an ACK:
> acknowledgement that the receiver takes responsibility for getting the
> transaction confirmed (to the extent possible, of course).

Ok, so if there is no
payment
_url specified in the PaymentRequest, then the wallet is responsible for
broadcasting
the transaction to the bitcoin network
.
Otherwise, the wallet should
rely on the merchant server to broadcast.


On Mon, Jan 27, 2014 at 2:17 PM, Pieter Wuille <pieter.wuille@gmail.com>wrote:

> On Mon, Jan 27, 2014 at 11:03 PM, Kevin Greene <kgreenek@gmail.com> wrote:
> > +1 for an error field.
>
> Agree, I think we need a way for client applications to interpret the
> response.
>
> > Should the wallet broadcast the transaction to the bitcoin network when
> it
> > receives an ACK, or always assume that the merchant server will do that?
>
> In my opinion, that should be the primary meaning of receiving an ACK:
> acknowledgement that the receiver takes responsibility for getting the
> transaction confirmed (to the extent possible, of course).


>
> --
> Pieter
>

[-- Attachment #2: Type: text/html, Size: 2877 bytes --]

Re: [Bitcoin-development] BIP70: PaymentACK semantics

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1627 bytes --]

Yeah, that's the interpretation I think we should go with for now. There
was a reason why this isn't specified and I forgot what it was - some
inability to come to agreement on when to broadcast vs when to submit via
HTTP, I think.




On Mon, Jan 27, 2014 at 11:39 PM, Kevin Greene <kgreenek@gmail.com> wrote:

> >> Should the wallet broadcast the transaction to the bitcoin network when
> it
> >> receives an ACK, or always assume that the merchant server will do that?
> >
> > In my opinion, that should be the primary meaning of receiving an ACK:
> > acknowledgement that the receiver takes responsibility for getting the
> > transaction confirmed (to the extent possible, of course).
>
> Ok, so if there is no
> payment
> _url specified in the PaymentRequest, then the wallet is responsible for
> broadcasting
> the transaction to the bitcoin network
> .
> Otherwise, the wallet should
> rely on the merchant server to broadcast.
>
>
> On Mon, Jan 27, 2014 at 2:17 PM, Pieter Wuille <pieter.wuille@gmail.com>wrote:
>
>> On Mon, Jan 27, 2014 at 11:03 PM, Kevin Greene <kgreenek@gmail.com>
>> wrote:
>> > +1 for an error field.
>>
>> Agree, I think we need a way for client applications to interpret the
>> response.
>>
>> > Should the wallet broadcast the transaction to the bitcoin network when
>> it
>> > receives an ACK, or always assume that the merchant server will do that?
>>
>> In my opinion, that should be the primary meaning of receiving an ACK:
>> acknowledgement that the receiver takes responsibility for getting the
>> transaction confirmed (to the extent possible, of course).
>
>
>>
>> --
>> Pieter
>>
>
>

[-- Attachment #2: Type: text/html, Size: 3616 bytes --]

Re: [Bitcoin-development] BIP70: PaymentACK semantics

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]

On Tue, Jan 28, 2014 at 6:42 AM, Mike Hearn <mike@plan99.net> wrote:

> Yeah, that's the interpretation I think we should go with for now. There
> was a reason why this isn't specified and I forgot what it was - some
> inability to come to agreement on when to broadcast vs when to submit via
> HTTP, I think.
>

If the wallet software is doing automatic CoinJoin (for example), then
typically one or several of the other participants will broadcast the
transaction as soon as it is complete.

If the spec said that wallets must not broadcast until they receive a
PaymentACK (if a payment_url is specified), then you'd have to violate the
spec to do CoinJoin.

And even if you don't care about CoinJoin, not broadcasting the transaction
as soon as the inputs are signed adds implementation complexity (should you
retry if payment_url is unavailable? how many times? if you eventually
unlock the probably-not-quite-spent-yet inputs, should you double-spend
them to yourself just in case the merchant eventually gets around to
broadcasting the transaction, or should you just unlock them and squirrel
away the failed Payment so if the merchant does eventually broadcast you
have a record of why the coins were spent).

-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 1651 bytes --]

Re: [Bitcoin-development] BIP70: PaymentACK semantics

[Pieter Wuille]

On Tue, Jan 28, 2014 at 1:53 PM, Gavin Andresen <gavinandresen@gmail.com> wrote:
> On Tue, Jan 28, 2014 at 6:42 AM, Mike Hearn <mike@plan99.net> wrote:
>>
>> Yeah, that's the interpretation I think we should go with for now. There
>> was a reason why this isn't specified and I forgot what it was - some
>> inability to come to agreement on when to broadcast vs when to submit via
>> HTTP, I think.
>
>
> If the wallet software is doing automatic CoinJoin (for example), then
> typically one or several of the other participants will broadcast the
> transaction as soon as it is complete.
>
> If the spec said that wallets must not broadcast until they receive a
> PaymentACK (if a payment_url is specified), then you'd have to violate the
> spec to do CoinJoin.

You cannot prevent transactions from being broadcasted, but an ACK can
still mean "You're now relieved of the responsibility of getting the
transaction confirmed". That's independent from being allowed to
broadcast it.

> And even if you don't care about CoinJoin, not broadcasting the transaction
> as soon as the inputs are signed adds implementation complexity (should you
> retry if payment_url is unavailable? how many times? if you eventually
> unlock the probably-not-quite-spent-yet inputs, should you double-spend them
> to yourself just in case the merchant eventually gets around to broadcasting
> the transaction, or should you just unlock them and squirrel away the failed
> Payment so if the merchant does eventually broadcast you have a record of
> why the coins were spent).

If a payment_url is unavailable, you should imho retry. If you
broadcasted, and the payment_url is unavailable, you should
*certainly* retry. Otherwise the recipient cannot rely on receiving
memo and refund address, which would imho make these fields completely
useless.

I still like suggesting not broadcasting if a payment_uri to minimize
that risk further, but as you say - there are enough cases where you
cannot enforce that anyway.

-- 
Pieter

Re: [Bitcoin-development] BIP70: PaymentACK semantics

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 844 bytes --]

>
> And even if you don't care about CoinJoin, not broadcasting the
> transaction as soon as the inputs are signed adds implementation complexity
> (should you retry if payment_url is unavailable? how many times?
>

I guess a lot of wallets just won't broadcast at all and try to submit via
the URL. If they don't succeed, then the transaction is just never
committed to the wallet. Doesn't seem like a big deal. Payment submission
is online, interactive. If it fails, you keep the coins. This seems simple
and straightforward.

If someone really wanted to do a real-time coinjoin, they can build the
transaction together and submit it via payment_url, and broadcast as well.
If the merchant has an issue with the payment for some reason (e.g. request
is expired or the tx is non-standard), well, you'll have to sort it out
with them manually.

[-- Attachment #2: Type: text/html, Size: 1195 bytes --]

Re: [Bitcoin-development] BIP70: PaymentACK semantics

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2288 bytes --]

On Tue, Jan 28, 2014 at 07:53:14AM -0500, Gavin Andresen wrote:
> On Tue, Jan 28, 2014 at 6:42 AM, Mike Hearn <mike@plan99.net> wrote:
> 
> > Yeah, that's the interpretation I think we should go with for now. There
> > was a reason why this isn't specified and I forgot what it was - some
> > inability to come to agreement on when to broadcast vs when to submit via
> > HTTP, I think.
> >
> 
> If the wallet software is doing automatic CoinJoin (for example), then
> typically one or several of the other participants will broadcast the
> transaction as soon as it is complete.
> 
> If the spec said that wallets must not broadcast until they receive a
> PaymentACK (if a payment_url is specified), then you'd have to violate the
> spec to do CoinJoin.
> 
> And even if you don't care about CoinJoin, not broadcasting the transaction
> as soon as the inputs are signed adds implementation complexity (should you
> retry if payment_url is unavailable? how many times? if you eventually
> unlock the probably-not-quite-spent-yet inputs, should you double-spend
> them to yourself just in case the merchant eventually gets around to
> broadcasting the transaction, or should you just unlock them and squirrel
> away the failed Payment so if the merchant does eventually broadcast you
> have a record of why the coins were spent).

Also users don't have infinite unspent txouts in their wallets - if they
need to make two payments in a row and run out their wallet software is
(currently) going to spend the change txout and either be forced to
broadcast both transactions anyway, or the second payment-protocol-using
recipient will do so on their behalf. (in the future they might also do
a replacement tx replacing the first with a single tx paying both to
save on fees, again with the same problem)

Anyway what you want is payment atomicity: the customer losing control
of the funds must be atomic with respect to the payment going through.
From that point of view it's unfortunate that Payment message contains
refund_to, memo, etc. That information should have been provided to the
merchant prior to them providing the list of addresses to pay.

-- 
'peter'[:-1]@petertodd.org
000000000000000085c725a905444d271c56fdee4e4ec7f27bdb2e777c872925

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] BIP70: PaymentACK semantics

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 3268 bytes --]

In practice this should only be an issue if a payment is submitted and
fails, which should be rare. Barring internal server errors and screwups on
the merchants side, the only reasons for a rejection at submit time would
be the imperfect fungibility of bitcoins, e.g. you try and pay with a huge
dust tx or one that's invalid/too low fee/etc.

So I think we have a bit of time to figure this out. But yes - once you
broadcast, you probably accept that there might be a more painful path to
resolve issues if something goes wrong, I guess. Right now BitPay has a
support system where you can file a ticket if you pay the bitcoins and they
don't recognise it or the tx never confirms or whatever. It's grotty manual
work but they do it. Not broadcasting unless you "have" to seems like an
optimisation that can reduce pain without much additional complexity.



On Tue, Jan 28, 2014 at 6:23 PM, Peter Todd <pete@petertodd.org> wrote:

> On Tue, Jan 28, 2014 at 07:53:14AM -0500, Gavin Andresen wrote:
> > On Tue, Jan 28, 2014 at 6:42 AM, Mike Hearn <mike@plan99.net> wrote:
> >
> > > Yeah, that's the interpretation I think we should go with for now.
> There
> > > was a reason why this isn't specified and I forgot what it was - some
> > > inability to come to agreement on when to broadcast vs when to submit
> via
> > > HTTP, I think.
> > >
> >
> > If the wallet software is doing automatic CoinJoin (for example), then
> > typically one or several of the other participants will broadcast the
> > transaction as soon as it is complete.
> >
> > If the spec said that wallets must not broadcast until they receive a
> > PaymentACK (if a payment_url is specified), then you'd have to violate
> the
> > spec to do CoinJoin.
> >
> > And even if you don't care about CoinJoin, not broadcasting the
> transaction
> > as soon as the inputs are signed adds implementation complexity (should
> you
> > retry if payment_url is unavailable? how many times? if you eventually
> > unlock the probably-not-quite-spent-yet inputs, should you double-spend
> > them to yourself just in case the merchant eventually gets around to
> > broadcasting the transaction, or should you just unlock them and squirrel
> > away the failed Payment so if the merchant does eventually broadcast you
> > have a record of why the coins were spent).
>
> Also users don't have infinite unspent txouts in their wallets - if they
> need to make two payments in a row and run out their wallet software is
> (currently) going to spend the change txout and either be forced to
> broadcast both transactions anyway, or the second payment-protocol-using
> recipient will do so on their behalf. (in the future they might also do
> a replacement tx replacing the first with a single tx paying both to
> save on fees, again with the same problem)
>
> Anyway what you want is payment atomicity: the customer losing control
> of the funds must be atomic with respect to the payment going through.
> From that point of view it's unfortunate that Payment message contains
> refund_to, memo, etc. That information should have been provided to the
> merchant prior to them providing the list of addresses to pay.
>
> --
> 'peter'[:-1]@petertodd.org
> 000000000000000085c725a905444d271c56fdee4e4ec7f27bdb2e777c872925
>

[-- Attachment #2: Type: text/html, Size: 4068 bytes --]

Re: [Bitcoin-development] BIP70: PaymentACK semantics

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2313 bytes --]

On Tue, Jan 28, 2014 at 06:33:28PM +0100, Mike Hearn wrote:
> In practice this should only be an issue if a payment is submitted and
> fails, which should be rare. Barring internal server errors and screwups on
> the merchants side, the only reasons for a rejection at submit time would
> be the imperfect fungibility of bitcoins, e.g. you try and pay with a huge
> dust tx or one that's invalid/too low fee/etc.
> 
> So I think we have a bit of time to figure this out. But yes - once you
> broadcast, you probably accept that there might be a more painful path to
> resolve issues if something goes wrong, I guess. Right now BitPay has a
> support system where you can file a ticket if you pay the bitcoins and they
> don't recognise it or the tx never confirms or whatever. It's grotty manual
> work but they do it. Not broadcasting unless you "have" to seems like an
> optimisation that can reduce pain without much additional complexity.

That's the reason you use a model where things happen atomicly: the
funds either can or can't be transferred, so if the merchant screws up
due to a server failure at worst the wallet can always send the
original, signed, payment request and transaction details proving to the
merchant that they agreed. Since the asked for txouts exist in the
blockchain they must either refund the money, or ship the goods.

Wallet software can handle that kind of worst-case failure by
automatically sending the original payment request back to the merchant.
At worst all customer support has to do is tell the customer "Sorry
about that; we didn't get your payment. Please start your wallet up and
hit the 'resend transaction' button in your wallet and we'll clear that
right up."

Keep in mind that we're probably going to see fraudsters figuring out
ways to make payment servers fail. This means conversely that a customer
calling up a merchant and saying "Hey! Something didn work but the
wallet says I paid!" is going to be treated more suspiciously. By using
atomic protocols the issue of did or didn't they pay becomes much more
black and white, and failure resistant. That's exactly what we keep
saying Bitcoin offers that PayPal doesn't.

-- 
'peter'[:-1]@petertodd.org
000000000000000085c725a905444d271c56fdee4e4ec7f27bdb2e777c872925

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] BIP70: PaymentACK semantics

[Jeff Garzik]

On Mon, Jan 27, 2014 at 5:17 PM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
> On Mon, Jan 27, 2014 at 11:03 PM, Kevin Greene <kgreenek@gmail.com> wrote:
> > Should the wallet broadcast the transaction to the bitcoin network when it
> > receives an ACK, or always assume that the merchant server will do that?

> In my opinion, that should be the primary meaning of receiving an ACK:
> acknowledgement that the receiver takes responsibility for getting the
> transaction confirmed (to the extent possible, of course).

Is this truly the intent?  That the merchant/processor takes full
responsibility for getting the TX confirmed?

It is within the customer's economic incentive -- and right as a free
person -- to work to get their transaction relayed to the network and
confirmed in parallel with whatever the merchant is doing.

BIP 70 states that the customer broadcasts the transaction, in
addition to sending the Payment message.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] BIP70: PaymentACK semantics

[Pieter Wuille]

On Thu, Jan 30, 2014 at 3:51 PM, Jeff Garzik <jgarzik@bitpay.com> wrote:
> On Mon, Jan 27, 2014 at 5:17 PM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
>> On Mon, Jan 27, 2014 at 11:03 PM, Kevin Greene <kgreenek@gmail.com> wrote:
>> > Should the wallet broadcast the transaction to the bitcoin network when it
>> > receives an ACK, or always assume that the merchant server will do that?
>
>> In my opinion, that should be the primary meaning of receiving an ACK:
>> acknowledgement that the receiver takes responsibility for getting the
>> transaction confirmed (to the extent possible, of course).
>
> Is this truly the intent?  That the merchant/processor takes full
> responsibility for getting the TX confirmed?

Confirmed is probably the wrong word. But IMHO (not how it's currently
worded), the merchant should take that responsibility after delivering
a PaymentACK. This means the client does not need to stay online
anymore. More importantly, it removes the requirement for the P2P
network to function as a reliable sender->receiver communication
channel (and reduces it to a broadcast medium to get transactions to
miners).

-- 
Pieter

Re: [Bitcoin-development] BIP70: PaymentACK semantics

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 521 bytes --]

>
> Is this truly the intent?  That the merchant/processor takes full
> responsibility for getting the TX confirmed?


As per Gavin at the top of the thread, the intent is to give the customer
reassurance that their payment will be processed. The merchant trying to
get the tx confirmed is presumably a part of that as it'd make no sense for
a merchant to give that assurance and decide they don't care about the
money.

But nothing stops the user broadcasting the tx as well, once the receiver
has given that assurance.

[-- Attachment #2: Type: text/html, Size: 844 bytes --]

Re: [Bitcoin-development] BIP70: PaymentACK semantics

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 564 bytes --]

On Thu, Jan 30, 2014 at 9:51 AM, Jeff Garzik <jgarzik@bitpay.com> wrote:

> Is this truly the intent?  That the merchant/processor takes full
> responsibility for getting the TX confirmed?
>

The intent is to give the customer a great experience. We could talk for
months about whether having the wallet broadcast the transaction as soon as
possible or having it wait for the merchant to respond with a PaymentACK is
better. But I think we should let wallets experiment with different ways of
doing it, and see what works best in practice.


-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 971 bytes --]

Re: [Bitcoin-development] BIP70: PaymentACK semantics

[Pieter Wuille]

On Thu, Jan 30, 2014 at 4:06 PM, Gavin Andresen <gavinandresen@gmail.com> wrote:
> On Thu, Jan 30, 2014 at 9:51 AM, Jeff Garzik <jgarzik@bitpay.com> wrote:
>>
>> Is this truly the intent?  That the merchant/processor takes full
>> responsibility for getting the TX confirmed?
>
>
> The intent is to give the customer a great experience. We could talk for
> months about whether having the wallet broadcast the transaction as soon as
> possible or having it wait for the merchant to respond with a PaymentACK is
> better. But I think we should let wallets experiment with different ways of
> doing it, and see what works best in practice.

Currently, with the specification and implementation in Bitcoin Core,
if a merchant wants to use the refund or memo feature, they need to
provide an alternative route for delivering that information to them
*before* the transaction is made, as sending the transaction may
result in the transfer of funds without knowing what to do with it (if
their receive server is down at the right time) and potnetially no way
to contact the sender. This makes these fields utterly useless.

This is not a matter of letting wallets experiment with the best
behaviour. This is removing the ability to rely on the payment
protocol being bidirectional.

I don't care whether wallets broadcast the transactions or not (they
can experiment with that as they like). But we should take measures to
prevent a transaction for being broadcast without the payment being
delivered. One way is never broadcasting the transaction yourself.
Another is retrying to send the payment if delivery fails.

Here is what I would suggest to add to the specification:
* If a payment_uri is specified, the client must attempt to send the
payment there.
* If a transaction is broadcast (which is permitted even if sending
the payment fails), a client should make a reasonable attempt of
delivering the payment (remembering, retrying, ...).
* If a paymentACK has been received, the client is no longer
responsible for broadcasting the transaction (but still may).

-- 
Pieter

Re: [Bitcoin-development] BIP70: PaymentACK semantics

[Jeremy Spilman]

Please note, responding to Pieter and Chuck concurrently.

On Thu, 30 Jan 2014 07:16:54 -0800, Pieter Wuille  
<pieter.wuille@gmail.com> wrote:
> Currently, with the specification and implementation in Bitcoin Core,
> if a merchant wants to use the refund or memo feature, they need to
> provide an alternative route for delivering that information to them
> *before* the transaction is made, as sending the transaction may
> result in the transfer of funds without knowing what to do with it (if
> their receive server is down at the right time) and potnetially no way
> to contact the sender. This makes these fields utterly useless.
>
> This is not a matter of letting wallets experiment with the best
> behaviour. This is removing the ability to rely on the payment
> protocol being bidirectional.

I think we want to separate the two issues;

   1) Reliably getting refund/memo fields to the merchant/payee
   2) Who broadcasts a TX, how it's retried, how outputs are 'locked' and  
if/when they should be [double]-spent to clear them

We should be able to solve '1' without having to fully spec out behavior  
for 2.

On Thu, 30 Jan 2014 07:16:54 -0800, Pieter Wuille  
<pieter.wuille@gmail.com> wrote:
> I don't care whether wallets broadcast the transactions or not (they
> can experiment with that as they like). But we should take measures to
> prevent a transaction for being broadcast without the payment being
> delivered. One way is never broadcasting the transaction yourself.
> Another is retrying to send the payment if delivery fails.
>
> Here is what I would suggest to add to the specification:
> * If a payment_uri is specified, the client must attempt to send the
> payment there.
> * If a transaction is broadcast (which is permitted even if sending
> the payment fails), a client should make a reasonable attempt of
> delivering the payment (remembering, retrying, ...).
> * If a paymentACK has been received, the client is no longer
> responsible for broadcasting the transaction (but still may).

To reliably deliver refund/memo fields, we could;

   a) Send them as part of the initial request for the  
PaymentRequest/PaymentDetails
   b) Send them as a response to the PaymentRequest/PaymentDetails before  
the transaction is even formed and any unspent outputs are selected
   c) Send them as a response to the PaymentRequest/PaymentDetails with the  
UNsigned transaction, and then follow up with the signed transaction in a  
separate message.

'a' is problematic because while wallet software could easily append some  
data to the queryString, it doesn't work if the user is downloading then  
opening the PaymentRequest as a file. So 'a' is a no-go I think.

'b' is fine, if not overly chatty. The only thing committed is a refund  
address, which is a lot less problematic than committed unspent outputs.

'c' is nice because it lets the server preview the transaction (and  
ACK/NACK it with a memo of their own -- e.g. 'fee too low'?) without being  
able to broadcast it, so we know unspent outputs are not yet committed.

But all of these require too many changes to the protocol for my liking.

On Wed, 29 Jan 2014 21:47:51 -0800, Chuck <chuck+bitcoindev@borboggle.com>  
wrote:
> 3. Customer builds a set of transactions and sends a new 
> PaymentApprovalRequest message which includes a refund address and the 
> unsigned transactions and their associated fully-signed transactionhash,  
> the whole message signed with the private key of the refund address.

"Unsigned transactions and their associated fully-signed transaction hash"  
-- isn't that a fully signed transaction? In this case, it doesn't solve  
the core problem of the server being able to broadcast that transaction  
without ACKing.

On Wed, 29 Jan 2014 21:47:51 -0800, Chuck <chuck+bitcoindev@borboggle.com>  
wrote:
> In Step 3, it's critical the customer sign the message with the private
> key of the refund address, so that the merchant can be confident the
> refund address is correct.

For merchant confidence that the address is correct, we can leave the  
transport security to the transport layer.

For payer proving refund address was X after merchant sends a refund to Y,  
that's a different story. I don't think we want to *require* access to the  
refund address private key. For example, BIP32 public derivation may have  
just the pubkey available. Offline transaction signing is one thing, but  
offline PP message signing is too much. I think there are better ways to  
secure the refund address which can reuse existing code, and certainly the  
option should remain to send a plain refund address just relying on  
transport security and trusting the merchant.

Re: [Bitcoin-development] BIP70: PaymentACK semantics

[Chuck]

On 1/31/2014 3:16 AM, Jeremy Spilman wrote:
> I think we want to separate the two issues;
>
>     1) Reliably getting refund/memo fields to the merchant/payee
>     2) Who broadcasts a TX, how it's retried, how outputs are 'locked' and
> if/when they should be [double]-spent to clear them
>
> We should be able to solve '1' without having to fully spec out behavior
> for 2.
My original message was focused on #1.  Not only #1, but ensuring the 
merchant can't act maliciously too.

As far as #2 is concerned, I don't think it makes any difference - it's 
in both the customer and the merchant's best interest to have the 
transactions confirmed.

>     c) Send them as a response to the PaymentRequest/PaymentDetails with the
> UNsigned transaction, and then follow up with the signed transaction in a
> separate message.
...
> On Wed, 29 Jan 2014 21:47:51 -0800, Chuck <chuck+bitcoindev@borboggle.com>
> wrote:
>> 3. Customer builds a set of transactions and sends a new
>> PaymentApprovalRequest message which includes a refund address and the
>> unsigned transactions and their associated fully-signed transactionhash,
>> the whole message signed with the private key of the refund address.
> "Unsigned transactions and their associated fully-signed transaction hash"
> -- isn't that a fully signed transaction? In this case, it doesn't solve
> the core problem of the server being able to broadcast that transaction
> without ACKing.
What I meant was (and maybe this was roundabout?): the customer includes 
the UNsigned transactions as well as the hashes (and only the hashes) of 
the fully signed transactions.  The customer keeps the fully signed 
transactions private until the merchant ACKs the unsigned versions.  If 
the merchant has the hash of the fully signed transaction, he can 
monitor the network for delivery of the signed transaction.

It definitely complicates things, but it's nothing that can't be done.

Cheers,

Chuck

Re: [Bitcoin-development] BIP70: PaymentACK semantics

[Christophe Biocca]

The merchant can always act maliciously by simply not delivering the
goods. The only recourse the payment protocol provides at that point
is that you have proof the merchant is acting maliciously (or at the
very least his payment system is broken).

Your scheme just adds an ACK of the specific unsigned transactions
before the payment is effectively irreversible.

I can't come up with a situation where the combination of signed
request and blockchain entry aren't enough evidence, yet where adding
an ACK by the merchant of the unsigned transaction tips the balance
the other way. If you know of such a possibility, I'd love to hear it,
because we'd know what we're trying to fix.

The only way I can see a malicious merchant exploiting wallet
behaviour around PaymentACK is by accepting the Payment message, not
broadcasting it, not returning an ACK, and hoping the wallet/user
retries paying with a new, non-conflicting transaction. Then he can
try milking multiple small payments out of the user before they
realize what happened, and broadcast them all at once, stealing more
funds than the user ever was willing to risk in the transaction. But
this is trivial to guard against at the wallet level (by making every
new payment conflict with all previous non-acked payments).

The non-reliability of getting memo/refund fields is a separate
problem, but it seems BitcoinJ's approach addresses that nicely.

On Thu, Jan 30, 2014 at 11:16 PM, Chuck <chuck+bitcoindev@borboggle.com> wrote:
> On 1/31/2014 3:16 AM, Jeremy Spilman wrote:
>> I think we want to separate the two issues;
>>
>>     1) Reliably getting refund/memo fields to the merchant/payee
>>     2) Who broadcasts a TX, how it's retried, how outputs are 'locked' and
>> if/when they should be [double]-spent to clear them
>>
>> We should be able to solve '1' without having to fully spec out behavior
>> for 2.
> My original message was focused on #1.  Not only #1, but ensuring the
> merchant can't act maliciously too.
>
> As far as #2 is concerned, I don't think it makes any difference - it's
> in both the customer and the merchant's best interest to have the
> transactions confirmed.
>
>>     c) Send them as a response to the PaymentRequest/PaymentDetails with the
>> UNsigned transaction, and then follow up with the signed transaction in a
>> separate message.
> ...
>> On Wed, 29 Jan 2014 21:47:51 -0800, Chuck <chuck+bitcoindev@borboggle.com>
>> wrote:
>>> 3. Customer builds a set of transactions and sends a new
>>> PaymentApprovalRequest message which includes a refund address and the
>>> unsigned transactions and their associated fully-signed transactionhash,
>>> the whole message signed with the private key of the refund address.
>> "Unsigned transactions and their associated fully-signed transaction hash"
>> -- isn't that a fully signed transaction? In this case, it doesn't solve
>> the core problem of the server being able to broadcast that transaction
>> without ACKing.
> What I meant was (and maybe this was roundabout?): the customer includes
> the UNsigned transactions as well as the hashes (and only the hashes) of
> the fully signed transactions.  The customer keeps the fully signed
> transactions private until the merchant ACKs the unsigned versions.  If
> the merchant has the hash of the fully signed transaction, he can
> monitor the network for delivery of the signed transaction.
>
> It definitely complicates things, but it's nothing that can't be done.
>
> Cheers,
>
> Chuck
>
> ------------------------------------------------------------------------------
> WatchGuard Dimension instantly turns raw network data into actionable
> security intelligence. It gives you real-time visual feedback on key
> security issues and trends.  Skip the complicated setup - simply import
> a virtual appliance and go from zero to informed in seconds.
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development