Mike Hearn [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 9:43 AM, Michael Gronager <gronager at ceptacle.com> wrote:
> * What if the SignedReceipt is not received AND the transactions IS posted on the p2p.
I think this is a problem with confusing terminology rather then the
spec itself.
The original formulation had a receipt being something generated
purely by the buyer. The signed Invoice message + the Bitcoin
transactions paying to the outputs + the merkle branches showing
acceptance by the network *is* the receipt.
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.
📝 Original message:On Tue, Nov 27, 2012 at 9:43 AM, Michael Gronager <gronager at ceptacle.com> wrote:
> * What if the SignedReceipt is not received AND the transactions IS posted on the p2p.
I think this is a problem with confusing terminology rather then the
spec itself.
The original formulation had a receipt being something generated
purely by the buyer. The signed Invoice message + the Bitcoin
transactions paying to the outputs + the merkle branches showing
acceptance by the network *is* the receipt.
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.