{"type":"rich","version":"1.0","author_name":"npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","author_url":"https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2013-09-24\n📝 Original message:BTW, on the \"make qrcodes more scannable\" front -- is it too late to change\nBIP 72 so the new param is just \"r\" instead of \"request\"? Every byte helps\nwhen it comes to qrcodes ...\n\n\nOn Tue, Aug 20, 2013 at 12:05 PM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\n\u003e I think the confidence of the tx is not really the users concern anyway.\n\u003e They wrote it so they know it's valid. If the merchant disagrees for some\n\u003e reason then the user can find out, out of band when the goods/services are\n\u003e not delivered.\n\u003e\n\u003e\n\u003e On Tue, Aug 20, 2013 at 1:19 AM, Gavin Andresen \u003cgavinandresen at gmail.com\u003ewrote:\n\u003e\n\u003e\u003e On Tue, Aug 20, 2013 at 8:15 AM, Andreas Petersson \u003candreas at petersson.at\u003ewrote:\n\u003e\u003e\n\u003e\u003e\u003e I was just reviewing the integration work to integrate the Payment\n\u003e\u003e\u003e Protocol into our products. Is there any notion of a standardized\n\u003e\u003e\u003e invoice serialisation? If i pay for two Burgers and one Club Mate, how\n\u003e\u003e\u003e would my Bitcoin Wallet be able to know that?\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e No. There are XML-based (shudder) standards for electronic invoicing that\n\u003e\u003e include all sorts of bells and whistles; the PaymentDetails message could\n\u003e\u003e easily encapsulate one of them in an 'invoice' field extension. Or we could\n\u003e\u003e reinvent the wheel and come up with our own, but I'd rather use an existing\n\u003e\u003e standard (or maybe a subset of an existing standard).\n\u003e\u003e\n\u003e\u003e I didn't want to wade into that swamp for the 1.0 version of the payment\n\u003e\u003e protocol.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\u003e Right now, i would simply\n\u003e\u003e\u003e put that into \"memo\" and come up with my own serialisation mechanism.\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e\u003e \"Two Burgers, one Club Mate\" seems pretty user-friendly.\n\u003e\u003e\n\u003e\u003e  Second, is there a way to communicate acceptance levels of TX\n\u003e\u003e\u003e (unconfirmed, 1 conf, 6 conf) maybe using several PaymentACK?\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e\u003e No, because the Payment-\u003ePaymentACK communication round-trip is done in\n\u003e\u003e one, non-persistent http request-response round-trip.\n\u003e\u003e\n\u003e\u003e I don't think we want to allow merchants to push messages to the wallet\n\u003e\u003e (wouldn't take long for merchants to use the opportunity to push annoying\n\u003e\u003e advertising at me, I think), and I don't think we want wallets to poll the\n\u003e\u003e merchant. Although maybe a payment protocol version 2.0 feature could be a\n\u003e\u003e PaymentACK extension that says \"ask me how the transaction is going at THIS\n\u003e\u003e URL in THIS many minutes.\"\n\u003e\u003e\n\u003e\u003e --\n\u003e\u003e --\n\u003e\u003e Gavin Andresen\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e Introducing Performance Central, a new site from SourceForge and\n\u003e\u003e AppDynamics. Performance Central is your source for news, insights,\n\u003e\u003e analysis and resources for efficient Application Performance Management.\n\u003e\u003e Visit us today!\n\u003e\u003e\n\u003e\u003e http://pubads.g.doubleclick.net/gampad/clk?id=48897511\u0026iu=/4140/ostg.clktrk\n\u003e\u003e _______________________________________________\n\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e\n\u003e\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130924/d1998d43/attachment.html\u003e"}