Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2014-01-28 📝 Original message:In practice this should ...
📅 Original date posted:2014-01-28
📝 Original message: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 at 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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140128/3d176184/attachment.html>;
📝 Original message: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 at 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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140128/3d176184/attachment.html>;