Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W8CXW-0002Sp-Sp for bitcoin-development@lists.sourceforge.net; Tue, 28 Jan 2014 17:33:34 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.173 as permitted sender) client-ip=209.85.214.173; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f173.google.com; Received: from mail-ob0-f173.google.com ([209.85.214.173]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1W8CXV-00009l-I9 for bitcoin-development@lists.sourceforge.net; Tue, 28 Jan 2014 17:33:34 +0000 Received: by mail-ob0-f173.google.com with SMTP id vb8so748026obc.32 for ; Tue, 28 Jan 2014 09:33:28 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.2.42 with SMTP id 10mr593348obr.73.1390930408123; Tue, 28 Jan 2014 09:33:28 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.76.99.112 with HTTP; Tue, 28 Jan 2014 09:33:28 -0800 (PST) In-Reply-To: <20140128172349.GA14168@savin> References: <20140128172349.GA14168@savin> Date: Tue, 28 Jan 2014 18:33:28 +0100 X-Google-Sender-Auth: oXfzv-stLfKo3ItKrwhlt7MPjJE Message-ID: From: Mike Hearn To: Peter Todd Content-Type: multipart/alternative; boundary=001a1134ad06e2347e04f10b3838 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1W8CXV-00009l-I9 Cc: Andreas Schildbach , Bitcoin Dev Subject: Re: [Bitcoin-development] BIP70: PaymentACK semantics X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 17:33:35 -0000 --001a1134ad06e2347e04f10b3838 Content-Type: text/plain; charset=UTF-8 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 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 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 > --001a1134ad06e2347e04f10b3838 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In practice this should only be an issue if a payment is s= ubmitted and fails, which should be rare. Barring internal server errors an= d screwups on the merchants side, the only reasons for a rejection at submi= t 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 painf= ul path to resolve issues if something goes wrong, I guess. Right now BitPa= y 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= 9;s grotty manual work but they do it. Not broadcasting unless you "ha= ve" to seems like an optimisation that can reduce pain without much ad= ditional complexity.



On Tue, Jan 28, 2014 at 6:23 PM, Peter Todd <<= a href=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org> wrote:
On T= ue, 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 wa= s - some
> > inability to come to agreement on when to broadcast vs when to su= bmit 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<= br> > transaction as soon as it is complete.
>
> If the spec said that wallets must not broadcast until they receive a<= br> > PaymentACK (if a payment_url is specified), then you'd have to vio= late the
> spec to do CoinJoin.
>
> And even if you don't care about CoinJoin, not broadcasting the tr= ansaction
> as soon as the inputs are signed adds implementation complexity (shoul= d you
> retry if payment_url is unavailable? how many times? if you eventually=
> unlock the probably-not-quite-spent-yet inputs, should you double-spen= d
> them to yourself just in case the merchant eventually gets around to > broadcasting the transaction, or should you just unlock them and squir= rel
> away the failed Payment so if the merchant does eventually broadcast y= ou
> have a record of why the coins were spent).

Also users don't have infinite unspent txouts in their wall= ets - 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<= br> 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]@pet= ertodd.org
000000000000000085c725a905444d271c56fdee4e4ec7f27bdb2e777c872925

--001a1134ad06e2347e04f10b3838--