[Bitcoin-ml] Community survey on new Bitcoin Cash address format

[freetrader]

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>