From: Christopher Allen <ChristopherA@lifewithalacrity.com>
To: Peter Gray <peter@coinkite.com>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>,
Wolf McNally <wolf@wolfmcnally.com>,
Shannon Appelcline <shannon.appelcline@gmail.com>
Subject: Re: [bitcoin-dev] Proposal for a few IANA mime-types related to Bitcoin
Date: Tue, 31 Aug 2021 13:02:44 -0700 [thread overview]
Message-ID: <CACrqygABxGBDHf4n68UxbHLg3Ai60c6Z9gcF=-XFc2FyoBSqeg@mail.gmail.com> (raw)
In-Reply-To: <20210831191800.GW91472@coinkite.com>
[-- Attachment #1: Type: text/plain, Size: 1487 bytes --]
On Tue, Aug 31, 2021 at 12:18 PM Peter D. Gray <peter@coinkite.com> wrote:
> QR Codes do not use IANA mime-types.
>
> If anyone wanted to use UR encoding for PSBT data in a web context (http),
> NFC, or email, it would probably be best to discourage them.
>
> While I can understand the need for UR encoding in animated QR
> codes, I don't think any other use-case could justify introducing
> a new word list (ByteWords), a unique checksum algo (Xoshiro256),
> fountain codes (Luby Transform) and CBOR... just to wrap a few k
> of binary.
>
> I do love CBOR though. It's the best.
UR is more than just a QR, it is URL conformant text that is optimized for
compression in QRs.
In particular, take a look at the explanation of the UR format at the 20m0s
mark in this video:
https://youtu.be/RYgOFSdUqWY
The rest of the video explains why we made the choices we did. We wanted to
leverage existing standards, but there were too many compromises expecially
give QR requirements. See the section on “Why Another Standard” in our
overview at
https://github.com/BlockchainCommons/crypto-commons/blob/master/Docs/ur-1-overview.md#why-another-standard
Note that the UR specification just is not just being adopted by wallet
vendors, but also a number of online services / transaction coordinators
that only have access watch-only keys. These services can then do a
crypto-request for the airgapped wallet to sign the PSBT.
— Christopher Allen
>
[-- Attachment #2: Type: text/html, Size: 2754 bytes --]
next prev parent reply other threads:[~2021-08-31 20:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.9346.1630015566.1160.bitcoin-dev@lists.linuxfoundation.org>
2021-08-31 18:27 ` [bitcoin-dev] Proposal for a few IANA mime-types related to Bitcoin Peter D. Gray
2021-08-31 19:01 ` Christopher Allen
2021-08-31 19:18 ` Peter D. Gray
2021-08-31 20:02 ` Christopher Allen [this message]
2021-08-31 19:46 ` Andrew Chow
2021-09-01 13:39 ` Peter D. Gray
2021-09-02 10:52 ` Dr Maxim Orlovsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CACrqygABxGBDHf4n68UxbHLg3Ai60c6Z9gcF=-XFc2FyoBSqeg@mail.gmail.com' \
--to=christophera@lifewithalacrity.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=peter@coinkite.com \
--cc=shannon.appelcline@gmail.com \
--cc=wolf@wolfmcnally.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox