Alex Kotenko [ARCHIVE] on Nostr: š Original date posted:2014-03-20 š Original message:Hi Andreas I'm ...
š
Original date posted:2014-03-20
š Original message:Hi Andreas
I'm implementing support for BIP70 in my POS at the moment, and I've just
realized that with options you're proposing usecase I'm looking for is not
covered.
Right now, before BIP70, I'm sending BIP21 URI via NFC or QR code, and I
need to still be able to use it for backwards compatibility. But at the
same time I want to be able to support BIP70. And also I want to avoid
using external servers, the concept of my POS is that everything is
happening between just payer's phone and payee's POS device. This means
that BIP72 HTTP(S) link inside Bitcoin URI is not suitable for me.
You're also offering an option to include Base43 encoded PR body right
inside the Bitcoin URI, but in a way that is not backwards compatible with
BIP21.
In the end this all means that there is no way for me to at the same time
keep backwards compatibility with all wallets not supporting NFC and BIP70
(all other wallets right now), and keep things inside POS without need for
external servers.
I understand your intention behind base43 encoding and noncompatible URI -
you want to make most possible use of QR codes. But I wonder - did you
compare this base43 to base64 encoded request in a binary QR code format?
How much do we actually win in total bytes capacity at a price of
noncompatibility and increased complexity?
And also maybe we can extend BIP72 to include encoded payment request in
the URL directly in a backwards compatible way?
Best regards,
Alex Kotenko
2014-03-02 11:50 GMT+00:00 Mike Hearn <mike at plan99.net>:
> Thanks Andreas.
>
> For BIP standardisation, I think the VIEW intent seems like an obvious
> one. Bluetooth support probably should come later if/when we put
> encryption/auth on the RFCOMM link (probably SSL).
>
>
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140320/bc8cc362/attachment.html>;
š Original message:Hi Andreas
I'm implementing support for BIP70 in my POS at the moment, and I've just
realized that with options you're proposing usecase I'm looking for is not
covered.
Right now, before BIP70, I'm sending BIP21 URI via NFC or QR code, and I
need to still be able to use it for backwards compatibility. But at the
same time I want to be able to support BIP70. And also I want to avoid
using external servers, the concept of my POS is that everything is
happening between just payer's phone and payee's POS device. This means
that BIP72 HTTP(S) link inside Bitcoin URI is not suitable for me.
You're also offering an option to include Base43 encoded PR body right
inside the Bitcoin URI, but in a way that is not backwards compatible with
BIP21.
In the end this all means that there is no way for me to at the same time
keep backwards compatibility with all wallets not supporting NFC and BIP70
(all other wallets right now), and keep things inside POS without need for
external servers.
I understand your intention behind base43 encoding and noncompatible URI -
you want to make most possible use of QR codes. But I wonder - did you
compare this base43 to base64 encoded request in a binary QR code format?
How much do we actually win in total bytes capacity at a price of
noncompatibility and increased complexity?
And also maybe we can extend BIP72 to include encoded payment request in
the URL directly in a backwards compatible way?
Best regards,
Alex Kotenko
2014-03-02 11:50 GMT+00:00 Mike Hearn <mike at plan99.net>:
> Thanks Andreas.
>
> For BIP standardisation, I think the VIEW intent seems like an obvious
> one. Bluetooth support probably should come later if/when we put
> encryption/auth on the RFCOMM link (probably SSL).
>
>
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140320/bc8cc362/attachment.html>;