{"type":"rich","version":"1.0","author_name":"npub14jv7tj33yt72yk8mljmvkck3p4xm5s3mxfpj289up38qqsn9dhkqeh00t4","author_url":"https://nostr.ae/npub14jv7tj33yt72yk8mljmvkck3p4xm5s3mxfpj289up38qqsn9dhkqeh00t4","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-03-20\n📝 Original message:Hi Andreas\n\n\nI'm implementing support for BIP70 in my POS at the moment, and I've just\nrealized that with options you're proposing usecase I'm looking for is not\ncovered.\n\nRight now, before BIP70, I'm sending BIP21 URI via NFC or QR code, and I\nneed to still be able to use it for backwards compatibility. But at the\nsame time I want to be able to support BIP70. And also I want to avoid\nusing external servers, the concept of my POS is that everything is\nhappening between just payer's phone and payee's POS device. This means\nthat BIP72 HTTP(S) link inside Bitcoin URI is not suitable for me.\n\nYou're also offering an option to include Base43 encoded PR body right\ninside the Bitcoin URI, but in a way that is not backwards compatible with\nBIP21.\n\nIn the end this all means that there is no way for me to at the same time\nkeep backwards compatibility with all wallets not supporting NFC and BIP70\n(all other wallets right now), and keep things inside POS without need for\nexternal servers.\n\nI understand your intention behind base43 encoding and noncompatible URI -\nyou want to make most possible use of QR codes. But I wonder - did you\ncompare this base43 to base64 encoded request in a binary QR code format?\nHow much do we actually win in total bytes capacity at a price of\nnoncompatibility and increased complexity?\n\nAnd also maybe we can extend BIP72 to include encoded payment request in\nthe URL directly in a backwards compatible way?\n\n\nBest regards,\nAlex Kotenko\n\n\n2014-03-02 11:50 GMT+00:00 Mike Hearn \u003cmike at plan99.net\u003e:\n\n\u003e Thanks Andreas.\n\u003e\n\u003e For BIP standardisation, I think the VIEW intent seems like an obvious\n\u003e one. Bluetooth support probably should come later if/when we put\n\u003e encryption/auth on the RFCOMM link (probably SSL).\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Flow-based real-time traffic analytics software. Cisco certified tool.\n\u003e Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer\n\u003e Customize your own dashboards, set traffic alerts and generate reports.\n\u003e Network behavioral analysis \u0026 security monitoring. All-in-one tool.\n\u003e\n\u003e http://pubads.g.doubleclick.net/gampad/clk?id=126839071\u0026iu=/4140/ostg.clktrk\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140320/bc8cc362/attachment.html\u003e"}