📅 Original date posted:2013-08-08
📝 Original message:On Thu, Aug 8, 2013 at 2:48 AM, Gavin Andresen <gavinandresen at gmail.com> wrote:
> I've updated the BIP 72 spec at https://en.bitcoin.it/wiki/BIP_0072 so
> the bitcoin address is optional:
>
> "If the "request" parameter is provided and backwards compatibility is
> not required, then the bitcoin address portion of the URI may be
> omitted (the URI will be of the form: bitcoin:?request=... )."
Sounds good.
I'd still like to see some effort to avoid losing metadata and
reducing the responsibilities of the sender.
I see there's an implementation difficulty in avoiding to broadcast a
transaction, but for example, if a payment_uri is specified, and it
cannot be contacted (at all), the transaction should fail. As soon as
you manage to connect, and have at least attempted to submit the
transaction, the merchant may have received it, and you want to mark
the coins spent, so store it after that point. But without such
protection we'll likely see a unnecessary payments happening without
metadata, when the payment server cannot be contacted for some reason.
Also, the receiver most certainly needs a P2P implementation (and
probably a strongly validating one) to verify incoming transactions,
so having him broadcast it shouldn't be hard. I don't think the client
should be required to stay online to broadcast at all, after a
paymentACK is received. The transaction arrived safely at that point.
--
Pieter
Pieter Wuille [ARCHIVE] /
npub1tj…jtl6r
2023-06-07 17:05:39
in reply to nevent1q…kesf
Author Public Key
npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rPublished at
2023-06-07 17:05:39Event JSON
{
"id": "0ed2f0d369858906968427f7732886ab86e273480f36fc99d9aab18c879e0e88",
"pubkey": "5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6",
"created_at": 1686150339,
"kind": 1,
"tags": [
[
"e",
"c5e56f29f73ae037803d4c07616ae2b1311014baf62f54f10973c0b1b685df68",
"",
"root"
],
[
"e",
"d4fa2856f453d931f02e90c685a5a06fc1298dfece1e2784b8f9349ec93982ac",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2013-08-08\n📝 Original message:On Thu, Aug 8, 2013 at 2:48 AM, Gavin Andresen \u003cgavinandresen at gmail.com\u003e wrote:\n\u003e I've updated the BIP 72 spec at https://en.bitcoin.it/wiki/BIP_0072 so\n\u003e the bitcoin address is optional:\n\u003e\n\u003e \"If the \"request\" parameter is provided and backwards compatibility is\n\u003e not required, then the bitcoin address portion of the URI may be\n\u003e omitted (the URI will be of the form: bitcoin:?request=... ).\"\n\nSounds good.\n\nI'd still like to see some effort to avoid losing metadata and\nreducing the responsibilities of the sender.\n\nI see there's an implementation difficulty in avoiding to broadcast a\ntransaction, but for example, if a payment_uri is specified, and it\ncannot be contacted (at all), the transaction should fail. As soon as\nyou manage to connect, and have at least attempted to submit the\ntransaction, the merchant may have received it, and you want to mark\nthe coins spent, so store it after that point. But without such\nprotection we'll likely see a unnecessary payments happening without\nmetadata, when the payment server cannot be contacted for some reason.\n\nAlso, the receiver most certainly needs a P2P implementation (and\nprobably a strongly validating one) to verify incoming transactions,\nso having him broadcast it shouldn't be hard. I don't think the client\nshould be required to stay online to broadcast at all, after a\npaymentACK is received. The transaction arrived safely at that point.\n\n-- \nPieter",
"sig": "587504eeee16ad40db9e38f213bc5c648705ed62a2da8377977d95208cb358206c7d9a72820b3e084fc5b03ec632aaf81e6d66f2db6833c7cdb7fce73bec1e59"
}