Pieter Wuille [ARCHIVE] on Nostr: 📅 Original date posted:2012-11-27 📝 Original message:On Tue, Nov 27, 2012 at ...
📅 Original date posted:2012-11-27
📝 Original message:On Tue, Nov 27, 2012 at 11:42:01AM +0100, Michael Gronager wrote:
> >
> > The SignedReceipt message is useful in the sense that it shows
> > confirmation by the merchant, but if you don't get one, you can still
> > prove you paid the invoice. So from this perspective perhaps
> > SignedReceipt should be renamed to Acceptance or something like that,
> > and then the spec should call out that a signed invoice plus accepted
> > Bitcoin transactions is mathematically a proof of purchase.
>
> Which is why I find the "SignedReceipt" somewhat superfluous. If you implement a payment system, like bit-pay/wallet you are likely to double that through some sort of e-mail receipt anyway.
Gavin's proposal differs in this from my original proposal, where I
exactly *didn't* want to couple the receipt with the acceptance of
the Bitcoin transaction.
If a merchant/payment processor is willing to take the risk of zero or
low confirmation transactions (because they are insured against it,
for example), they were allowed to reply "accepted" immediately, and
this would be a permanent proof of payment, even if the actual Bitcoin
transaction that backs it gets reverted.
For that reason, I also had a separate "pending" state, which means the
receiver isn't willing to just accept the current state as irrevocably
paid. In this case, the sender was allowed to retry until the receipt
sayd "accepted" or "rejected".
The whole point was to avoid that customers/merchants would have to
deal with the uncertainty involved in Bitcoin transaction. At some
point, someone is going to accept the transaction (whether that is at
0 or at 120 confirmations), and acceptance will at the higher level
be considered a boolean anyway - not some "probably, unless reorg".
--
Pieter
📝 Original message:On Tue, Nov 27, 2012 at 11:42:01AM +0100, Michael Gronager wrote:
> >
> > The SignedReceipt message is useful in the sense that it shows
> > confirmation by the merchant, but if you don't get one, you can still
> > prove you paid the invoice. So from this perspective perhaps
> > SignedReceipt should be renamed to Acceptance or something like that,
> > and then the spec should call out that a signed invoice plus accepted
> > Bitcoin transactions is mathematically a proof of purchase.
>
> Which is why I find the "SignedReceipt" somewhat superfluous. If you implement a payment system, like bit-pay/wallet you are likely to double that through some sort of e-mail receipt anyway.
Gavin's proposal differs in this from my original proposal, where I
exactly *didn't* want to couple the receipt with the acceptance of
the Bitcoin transaction.
If a merchant/payment processor is willing to take the risk of zero or
low confirmation transactions (because they are insured against it,
for example), they were allowed to reply "accepted" immediately, and
this would be a permanent proof of payment, even if the actual Bitcoin
transaction that backs it gets reverted.
For that reason, I also had a separate "pending" state, which means the
receiver isn't willing to just accept the current state as irrevocably
paid. In this case, the sender was allowed to retry until the receipt
sayd "accepted" or "rejected".
The whole point was to avoid that customers/merchants would have to
deal with the uncertainty involved in Bitcoin transaction. At some
point, someone is going to accept the transaction (whether that is at
0 or at 120 confirmations), and acceptance will at the higher level
be considered a boolean anyway - not some "probably, unless reorg".
--
Pieter