Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2014-01-30 📝 Original message:Hi Chuck, Both Bitcoin ...
📅 Original date posted:2014-01-30
📝 Original message:Hi Chuck,
Both Bitcoin Core and bitcoinj are about to ship with the protocol as-is,
so any changes from this point on have to be backwards compatible.
On Thu, Jan 30, 2014 at 6:47 AM, Chuck <chuck+bitcoindev at borboggle.com>wrote:
> I presume the receipt R=(PaymentRequest,[transactions]) would suffice.
>
That's all you need to prove payment, yes.
> In the well-behaved case, I presume the point is to help the
> merchant associate some arbitrary data with the purchase as well as
> provide a refunding address for the customer.
That's right (+memo). And to provide an additional hook for future
features, like recurring billing, ECDH key agreements etc.
> In Step 3, it's critical the customer sign the message with the private
> key of the refund address, so that the merchant can be confident the
> refund address is correct.
>
Refund addresses as specced currently are optional. For instance bitcoinj
currently doesn't use them and won't until HD wallets support is done.
Let's get some practical experience with what we've got so far. We can
evolve PaymentRequest/Payment/PaymentACK in the right direction with
backwards compatible upgrades, I am hoping.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140130/c3bc08b3/attachment.html>;
📝 Original message:Hi Chuck,
Both Bitcoin Core and bitcoinj are about to ship with the protocol as-is,
so any changes from this point on have to be backwards compatible.
On Thu, Jan 30, 2014 at 6:47 AM, Chuck <chuck+bitcoindev at borboggle.com>wrote:
> I presume the receipt R=(PaymentRequest,[transactions]) would suffice.
>
That's all you need to prove payment, yes.
> In the well-behaved case, I presume the point is to help the
> merchant associate some arbitrary data with the purchase as well as
> provide a refunding address for the customer.
That's right (+memo). And to provide an additional hook for future
features, like recurring billing, ECDH key agreements etc.
> In Step 3, it's critical the customer sign the message with the private
> key of the refund address, so that the merchant can be confident the
> refund address is correct.
>
Refund addresses as specced currently are optional. For instance bitcoinj
currently doesn't use them and won't until HD wallets support is done.
Let's get some practical experience with what we've got so far. We can
evolve PaymentRequest/Payment/PaymentACK in the right direction with
backwards compatible upgrades, I am hoping.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140130/c3bc08b3/attachment.html>;