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

[Chris Priest]

> 1. Would it help or hinder your use cases if a distinct address format
>   were to be introduced for Bitcoin Cash addresses?

If bech32 is chosen it will hinder. If the bitpay proposal is chosed]n, it
will hinder it much less. The best solution is no change at all.

> 2. In your business or personal use, have you encountered a problem due
>   to existing Bitcoin Cash addresses being indistinguishable from
>   legacy Bitcoin addresses?

Never.

>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?

No. Don't fix what ain't broken. There are many instances of altcoins using
the same version byte and it's never a problem from what I can tell.


(a) VISUALLY DISTINCT


        not very important

   (b) COMPACTNESS of the format

        unimportant

   (c) MACHINE EFFICIENCY OF ENCODING

        unimportant

   (d) MACHINE EFFICIENCY OF DECODING

        unimportant

   (e) ERROR DETECTION ABILITY
       (whether it is important that a new format detects errors in
        address input better than the legacy format)

        unimportant (base58 error correction is more than enough)

   (f) ERROR CORRECTION ABILITY

        unimportant

   (g) HUMAN CONVERTIBILITY

        unimportant (you already trust wallet software to make
transactions, whats wrong with having to trust the same software to convert
your addresses?)

   (h) EXTENSIBILTY

        unimportant

   (i) ABILITY TO TRANSPORT HASHES LONGER THAN 160 BITS

        unimportant (the current base58 format can be modified to use
longer hashes when the time comes)

   (k) ENCODING IN ALPHANUMERIC MODE OF QR CODES

        unimportant (I've never had a problem decoding base58 address QR
codes)

   (m) DOUBLE-CLICKABLE

        important

   (n) SIMPLICITY OF SOFTWARE IMPLEMENTATION

        important (protocols should strive for maximum ease of
implementation. A lot of wallets are built by non-cryptography phD's, if
you make it too difficult, those wallets just won't implement BCH. At the
end of the day, BCH to many people is just another altcoin, so they won't
jump through hoops to implement BCH if it's too difficult. The replay
protection is already a difficult enough hoop)

5. Would you prefer a new format to remain case-sensitive or to be
   case-insensitive?

     sensitive

----------------------------------------------------------------------

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

----------------------------------------------------------------------

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.  no-change
     2.  bitpay
     3.  badami
     4. cashaddr

8. Any further comments

The problem I see with the badami proposal is that it's a scheme that only
BCH is likely to ever implement it. The bitpay proposal is using the same
address differentiation scheme that just about every altcoin in the
universe uses.

On Sun, Nov 19, 2017 at 6:35 PM, Roy Badami via bitcoin-ml <
bitcoin-ml at lists.linuxfoundation.org> wrote:

> Couple of comments on assumptions implicit in your questions.
>
> > (e) ERROR DETECTION ABILITY
> > (whether it is important that a new format detects errors in
> > address input better than the legacy format)
>
> I think it's important to view this question in the context of the
> fact that the existing format and all proposed formats have at worst a
> one-in-a-billion probability of accepting an invalid address.
>
> > (f) ERROR CORRECTION ABILITY
> > (whether it is important that a new format allows error
> > correction in bad address input)
>
> None of the formats are proposing error correction as far as I'm
> aware.  Although Bose-Chaudhuri-Hocquenghem codes are capable of error
> correction, I'm not sure anyone is proposing they are used for such a
> purpose.  Certainly BIP173 says this should *not* be done, due to the
> risks of a user accepting a bad suggested correction.
>
> > (i) ABILITY TO TRANSPORT HASHES LONGER THAN 160 BITS
> > (whether it is important that a new format is suitable for
> > (representing larger hashes)
>
> base58 is already used to encode data longer than 160 bits
> (e.g. private keys, xpubs and xprvs).  base58 has no intrinsic limit
> to data length.
>
> Regards,
>
> roy
> _______________________________________________
> bitcoin-ml mailing list
> bitcoin-ml at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml
>



-- 
Chris Priest
786-531-5938
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20171120/fed42ac8/attachment.html>