📅 Original date posted:2013-08-07
📝 Original message:On Wed, Jul 31, 2013 at 05:30:46PM -0600, E willbefull wrote:
> I think it's important to expect PaymentRequest-only bitcoin URIs in the
> future. Some types of payments (exotic transactions) may not make sense to
> have a single fallback address. Or, a page with a bitcoin URI link may be
> relying on a separate service provider to assemble the transaction.
Also:
* There may be a desire to minimize the URL length when used in a QR code
* Some applications might specifically require some of the features of
the payment protocol - e.g. it may be a requirement that a print-media
QR code cannot be used after a cut-off date, or a vendor may have a
specific requirement not to accept payments without a refund address
There are pros and cons, but it's not clear to me that the benefits of
enforced backward compatibility outweigh the benefits of allowing
application designers to innovate as they see fit.
roy
Roy Badami [ARCHIVE] /
npub1tr…0f95j
2023-06-07 15:05:36
in reply to nevent1q…urq9
Author Public Key
npub1trckpcxmceskq4cykxgwxm63n8ugrjrpu5mk83c90e4upsf7d9gqf0f95jPublished at
2023-06-07 15:05:36Event JSON
{
"id": "95217e6a767cc3ec41262912d0f484f8dcb29c717aca707fab21e8bd15fe6cbb",
"pubkey": "58f160e0dbc661605704b190e36f5199f881c861e53763c7057e6bc0c13e6950",
"created_at": 1686150336,
"kind": 1,
"tags": [
[
"e",
"c5e56f29f73ae037803d4c07616ae2b1311014baf62f54f10973c0b1b685df68",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2013-08-07\n📝 Original message:On Wed, Jul 31, 2013 at 05:30:46PM -0600, E willbefull wrote:\n\u003e I think it's important to expect PaymentRequest-only bitcoin URIs in the\n\u003e future. Some types of payments (exotic transactions) may not make sense to\n\u003e have a single fallback address. Or, a page with a bitcoin URI link may be\n\u003e relying on a separate service provider to assemble the transaction.\n\nAlso:\n\n* There may be a desire to minimize the URL length when used in a QR code\n\n* Some applications might specifically require some of the features of\nthe payment protocol - e.g. it may be a requirement that a print-media\nQR code cannot be used after a cut-off date, or a vendor may have a\nspecific requirement not to accept payments without a refund address\n\nThere are pros and cons, but it's not clear to me that the benefits of\nenforced backward compatibility outweigh the benefits of allowing\napplication designers to innovate as they see fit.\n\nroy",
"sig": "bc7de1e11d850efc4aab02132e990058a20a8e8c25068508d294d7cb56acdbd03971bea516ac63f170bd1c952cb8568dc6669e3d686ff044df5fc90c1952d913"
}