Lucas Ontivero [ARCHIVE] on Nostr: 📅 Original date posted:2017-03-30 📝 Original message:I don't know if i should ...
📅 Original date posted:2017-03-30
📝 Original message:I don't know if i should response to this mail list or make a comment in
commit file (
https://github.com/sipa/bech32/commit/52b5a0fa6d3174c4150393fb7d6b58d34b4f5e0b#diff-d23a42e5c904045098e8f8b1189f481e
)
* Motivation:
Here I think it could worth to mention that 58 requires mathematical
operations over big numbers. This is not very fast and most of the
programming languages don't provide support for big numbers OOB.
* Why not make an address format that is generic for all scriptPubKeys?:
I understand that if a new generic encoding format is introduced that could
lead to some confusions but what if in the future there is a new type of
address that can also be encoded with bech32? Don't we need a address type
anyway?
thx
2017-03-29 7:07 GMT-03:00 Andreas Schildbach via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> On 03/21/2017 08:14 PM, Peter Todd via bitcoin-dev wrote:
> > On Tue, Mar 21, 2017 at 05:16:30PM +0100, Andreas Schildbach via
> bitcoin-dev wrote:
> >> Why use Base 32 when the QR code alphanumeric mode allows 44 characters?
> >> In Bitcoin Wallet, I use Base 43 (alphabet:
> >> "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ$*+-./:") for most efficient QR
> >> code encoding. I only leave out the space character because it gets
> >> replaced by "+" in URLs.
> >
> > Doing that only makes addresses a few % shorter, at the cost of
> significant
> > downsides. For example, not everyone knows what those additional
> characters
> > are called, particularly for non-English-speaking users. Non-alphanumeric
> > characters also complicate using the addresses in a variety of contexts
> ('/'
> > in particularly isn't valid in filenames).
>
> I'm not convinced that transmitting addresses via voice should be a
> usecase to target at. I don't understand your comment about non-english
> speaking users. Obviously they cannot voice-communicate at all with
> only-english-speaking users, so there is no need to communicate
> voice-communicate addresses between them.
>
> Addresses in QR codes, addresses in URLs and addresses in NFC NDEF
> messages are the three most used forms.
>
> Speaking of URLs, actually Base 32 (as well as Base 43) makes QR codes
> *bigger* because due to the characters used for URL parameters (?&=)
> those QR codes are locked to binary mode. To make them shorter, we'd
> need to use something like "Base 64url" (or ideally Base 94 -- all
> printable ASCII characters).
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170330/7daa6736/attachment-0001.html>;
📝 Original message:I don't know if i should response to this mail list or make a comment in
commit file (
https://github.com/sipa/bech32/commit/52b5a0fa6d3174c4150393fb7d6b58d34b4f5e0b#diff-d23a42e5c904045098e8f8b1189f481e
)
* Motivation:
Here I think it could worth to mention that 58 requires mathematical
operations over big numbers. This is not very fast and most of the
programming languages don't provide support for big numbers OOB.
* Why not make an address format that is generic for all scriptPubKeys?:
I understand that if a new generic encoding format is introduced that could
lead to some confusions but what if in the future there is a new type of
address that can also be encoded with bech32? Don't we need a address type
anyway?
thx
2017-03-29 7:07 GMT-03:00 Andreas Schildbach via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> On 03/21/2017 08:14 PM, Peter Todd via bitcoin-dev wrote:
> > On Tue, Mar 21, 2017 at 05:16:30PM +0100, Andreas Schildbach via
> bitcoin-dev wrote:
> >> Why use Base 32 when the QR code alphanumeric mode allows 44 characters?
> >> In Bitcoin Wallet, I use Base 43 (alphabet:
> >> "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ$*+-./:") for most efficient QR
> >> code encoding. I only leave out the space character because it gets
> >> replaced by "+" in URLs.
> >
> > Doing that only makes addresses a few % shorter, at the cost of
> significant
> > downsides. For example, not everyone knows what those additional
> characters
> > are called, particularly for non-English-speaking users. Non-alphanumeric
> > characters also complicate using the addresses in a variety of contexts
> ('/'
> > in particularly isn't valid in filenames).
>
> I'm not convinced that transmitting addresses via voice should be a
> usecase to target at. I don't understand your comment about non-english
> speaking users. Obviously they cannot voice-communicate at all with
> only-english-speaking users, so there is no need to communicate
> voice-communicate addresses between them.
>
> Addresses in QR codes, addresses in URLs and addresses in NFC NDEF
> messages are the three most used forms.
>
> Speaking of URLs, actually Base 32 (as well as Base 43) makes QR codes
> *bigger* because due to the characters used for URL parameters (?&=)
> those QR codes are locked to binary mode. To make them shorter, we'd
> need to use something like "Base 64url" (or ideally Base 94 -- all
> printable ASCII characters).
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170330/7daa6736/attachment-0001.html>;