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
Published at
2023-06-07 10:40:57Event JSON
{
"id": "925c4b31c0902fecaeffd914944c6f0bd3e4379d919e7a5b60e32fc36add8efd",
"pubkey": "5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6",
"created_at": 1686134457,
"kind": 1,
"tags": [
[
"e",
"f5f2400f8aa8a7067be3d080f096fd7cbfeecdd6e589c178b85b63a9338150a5",
"",
"root"
],
[
"e",
"9644741c5d61b2ae41979791f2f7c1392d8f655fe21845c8b93a1c0225f4130e",
"",
"reply"
],
[
"p",
"9e3c76fd7eb862ca37f150391debc7baa4f8423eaa3f894c476a7d4360de9a02"
]
],
"content": "📅 Original date posted:2012-11-27\n📝 Original message:On Tue, Nov 27, 2012 at 11:42:01AM +0100, Michael Gronager wrote:\n\u003e \u003e \n\u003e \u003e The SignedReceipt message is useful in the sense that it shows\n\u003e \u003e confirmation by the merchant, but if you don't get one, you can still\n\u003e \u003e prove you paid the invoice. So from this perspective perhaps\n\u003e \u003e SignedReceipt should be renamed to Acceptance or something like that,\n\u003e \u003e and then the spec should call out that a signed invoice plus accepted\n\u003e \u003e Bitcoin transactions is mathematically a proof of purchase.\n\u003e \n\u003e 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.\n\nGavin's proposal differs in this from my original proposal, where I\nexactly *didn't* want to couple the receipt with the acceptance of\nthe Bitcoin transaction.\n\nIf a merchant/payment processor is willing to take the risk of zero or\nlow confirmation transactions (because they are insured against it,\nfor example), they were allowed to reply \"accepted\" immediately, and\nthis would be a permanent proof of payment, even if the actual Bitcoin\ntransaction that backs it gets reverted.\n\nFor that reason, I also had a separate \"pending\" state, which means the\nreceiver isn't willing to just accept the current state as irrevocably\npaid. In this case, the sender was allowed to retry until the receipt\nsayd \"accepted\" or \"rejected\".\n\nThe whole point was to avoid that customers/merchants would have to\ndeal with the uncertainty involved in Bitcoin transaction. At some\npoint, someone is going to accept the transaction (whether that is at\n0 or at 120 confirmations), and acceptance will at the higher level\nbe considered a boolean anyway - not some \"probably, unless reorg\".\n\n-- \nPieter",
"sig": "5cbe435bf34f2f1828d8a9807f583c72046c9b1a23fc4e16f12395706203a4153d765acb5c3ca474a8fb4059d70077516feda46d0ba3edbcfcce8d02fe32cdbb"
}