Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2014-01-28 📝 Original message:On Tue, Jan 28, 2014 at ...
📅 Original date posted:2014-01-28
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 685 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140128/ed5c7f71/attachment.sig>;
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 685 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140128/ed5c7f71/attachment.sig>;