[Bitcoin-ml] Community survey on new Bitcoin Cash address format
freetrader
freetrader at tuta.io
Mon Nov 20 00:15:03 UTC 2017
Hello all,
This is a short survey for those who would be affected by a decision
to introduce to a new address format for Bitcoin Cash. The intention
is to better understand where your preference lies and why.
Of course you are free to ignore this survey entirely if you wish :-)
I've included the three proposals of which I'm aware.
If you know of any others which are not minor variants of one of the
included, please add them to the list of references and responses to relevant
questions / replies.
The penultimate question does allow for a 'No-change' choice if you
feel that the address format should not be changed at all.
INSTRUCTIONS
Please replace each "answer line" by the answer you choose, and leave
the rest of the text as context in your reply. Further instructions accompany
the questions where needed.
----------------------------------------------------------------------
1. Would it help or hinder your use cases if a distinct address format
were to be introduced for Bitcoin Cash addresses?
Possible answers (pick the one that dominates):
help // hinder // not affect // not sure
----------------------------------------------------------------------
2. In your business or personal use, have you encountered a problem due
to existing Bitcoin Cash addresses being indistinguishable from
legacy Bitcoin addresses?
yes // no
----------------------------------------------------------------------
3. Leaving your personal use cases aside, do you think it would be good
for Bitcoin Cash as an ecosystem to introduce a new address format?
(you can answer this question later if you first want to answer the
following ones to come to a decision for yourself)
yes // no // not sure
----------------------------------------------------------------------
4. Please judge the importance of each of the following attributes for
a new address scheme, from your perspective:
(a) VISUALLY DISTINCT
(whether a new-format address should be visually very distinct
from a legacy address)
unimportant // not very important // neutral // important // extremely important
(b) COMPACTNESS of the format
(whether the length of a new-format address matters compared to
current legacy address)
unimportant // not very important // neutral // important // extremely important
(c) MACHINE EFFICIENCY OF ENCODING
(whether a new format would be more efficiently encodable by
a computer software)
unimportant // not very important // neutral // important // extremely important
(d) MACHINE EFFICIENCY OF DECODING
(whether a new format would be more efficiently decodable by
a computer software)
unimportant // not very important // neutral // important // extremely important
(e) ERROR DETECTION ABILITY
(whether it is important that a new format detects errors in
address input better than the legacy format)
unimportant // not very important // neutral // important // extremely important
(f) ERROR CORRECTION ABILITY
(whether it is important that a new format allows error
correction in bad address input)
unimportant // not very important // neutral // important // extremely important
(g) HUMAN CONVERTIBILITY
(whether it is important that conversion between legacy and new
format can be done by people without any software)
unimportant // not very important // neutral // important // extremely important
(h) EXTENSIBILTY
(whether it is important that a new format has built-in
extensibilty)
unimportant // not very important // neutral // important // extremely important
(i) ABILITY TO TRANSPORT HASHES LONGER THAN 160 BITS
(whether it is important that a new format is suitable for
representing larger hashes)
unimportant // not very important // neutral // important // extremely important
(k) ENCODING IN ALPHANUMERIC MODE OF QR CODES
(whether it is important that a new format is encodable in
alphanumeric mode of QR codes)
unimportant // not very important // neutral // important // extremely important
(m) DOUBLE-CLICKABLE
(whether it is important that a new format address is selectable
by double-click in one action)
unimportant // not very important // neutral // important // extremely important
(n) SIMPLICITY OF SOFTWARE IMPLEMENTATION
(whether the software to implement a new format address should
be simple)
unimportant // not very important // neutral // important // extremely important
----------------------------------------------------------------------
5. Would you prefer a new format to remain case-sensitive or to be
case-insensitive?
sensitive // insensitive // don't care // unsure
----------------------------------------------------------------------
6. Have you read the existing proposals for a new Bitcoin Cash address
format?
( see references at the bottom for links to the proposals:
Bitpay [1], cashaddr [2], Roy Badami [3] )
yes // no
----------------------------------------------------------------------
7. Please rank the following proposals in order of your preference:
No-change, Bitpay, cashaddr, Badami
(rank 1 being the one you prefer the most)
1.
2.
3.
4.
----------------------------------------------------------------------
8. Any further comments
----------------------------------------------------------------------
Proposal references:
[1] https://support.bitpay.com/hc/en-us/articles/115004671663 ,
https://blog.bitpay.com/bitcoin-cash-wallet-beta
[2] https://github.com/Bitcoin-UAHF/spec/blob/master/cashaddr.md
[3] https://lists.linuxfoundation.org/pipermail/bitcoin-ml/2017-November/000520.html
--
freetrader at tuta.io
GPG fingerprint: CC32 9A4F B0E4 1392 8295 05FE C07A 7C34 5E86 B06C
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20171120/952a81ae/attachment-0001.html>
More information about the bitcoin-ml
mailing list