Gavin Andresen [ARCHIVE] on Nostr: š Original date posted:2012-11-29 š Original message:On Thu, Nov 29, 2012 at ...
š
Original date posted:2012-11-29
š Original message:On Thu, Nov 29, 2012 at 12:07 PM, Roy Badami <roy at gnomon.org.uk> wrote:
> I'd still like to understand the rationale for having the merchant
> broadcast the transaction - it seems to add complexity and create edge
> cases.
Mike Hearn has experimented with in-person payments using
bluetooth/NFC on a phone, where the merchant has full Internet
connectivity but the phone might only be able to connect to the
merchant via a Bluetooth/NFC paymentURI.
I think I agree with you, though: if the device DOES have
bitcoin-p2p-network-connectivity, then expecting the client to
broadcast the transaction might be cleaner.
However, if a connection to the paymentURI is made and the transaction
data has been sent, clients have to deal with the case where the
merchant also broadcasts the transaction, no matter what the spec says
and even if the merchant sends an "accepted : false" response.
--
--
Gavin Andresen
š Original message:On Thu, Nov 29, 2012 at 12:07 PM, Roy Badami <roy at gnomon.org.uk> wrote:
> I'd still like to understand the rationale for having the merchant
> broadcast the transaction - it seems to add complexity and create edge
> cases.
Mike Hearn has experimented with in-person payments using
bluetooth/NFC on a phone, where the merchant has full Internet
connectivity but the phone might only be able to connect to the
merchant via a Bluetooth/NFC paymentURI.
I think I agree with you, though: if the device DOES have
bitcoin-p2p-network-connectivity, then expecting the client to
broadcast the transaction might be cleaner.
However, if a connection to the paymentURI is made and the transaction
data has been sent, clients have to deal with the case where the
merchant also broadcasts the transaction, no matter what the spec says
and even if the merchant sends an "accepted : false" response.
--
--
Gavin Andresen