[Bitcoin-ml] Proposal to deploy cashaddr January, 14

Wed Nov 15 11:37:41 UTC 2017

I like the idea of fixing the addresses to avoid mixups on the wallet
level. I also like the increased checksum features. I do think that having
an address that is double click selectable is important. (No “:”s please.)

Finally I would say base58 is generally easier to read in so far as being
to quickly identify an address by sight due to visual differences
throughout the address. It makes it sort of like looking at a key. You can
tell the difference between 2 of them immediately. Base 32 especially
addresses which use only one case all look alike at a glance and will make
reading lists of addresses such as in a block explorer an eyesore.

On Wed, Nov 15, 2017 at 18:53 Erik Beijnoff via bitcoin-ml <
bitcoin-ml at lists.linuxfoundation.org> wrote:

> Good points Andrew.
>
> Just want to add that the convention of using digits (1,3 etc) as a prefix
> of an address is *very* difficult for normal users to get their head
> around, single letters as well. You can never expect them to understand
> that this maps to different technical implementations under the hood.
> Especially considering that the rest of the address that follows is a lot
> of similar digits and letters.
>
> It should only be used as a safe guard so that an address isn’t
> incorrectly pasted in the wrong place, and as a visual hint for those that
> do understand.
>
> Regards Erik
>
> On 15 Nov 2017, at 10:31, Andrew Clifford via bitcoin-ml <
> bitcoin-ml at lists.linuxfoundation.org> wrote:
>
> Bitcoin Cash is a fresh start and a major takeaway from Core's problems is
> that users are king. Changes should be demand-driven.
> If many users are experiencing problems with address confusion then we
> should help them. So Amaury's proposal is welcome.
>
> We also need to hold true to the "look-and-feel" of Bitcoin, of which all
> its users have some familiarity. With an intangible digital currency, one
> of the major visual anchor points is the recognisable Bitcoin address.
>
> I agree with Lucas that a prefix is highly desirable. Satoshi was smart to
> simply prefix them with "1". Obviously "3" has since been used since, and
> "5" occurs on private keys.
> Why not use another digit?. I first thought of "9" as it is perhaps last
> to find usage in a future Bitcoin Core. However, "8" is just as good and is
> very popular in Chinese culture, which is a bonus :-)
>
> Hence, modifying the example:
>     bitcoincash:8qpzry9x8gf2tvdw0s3jn54khce6mua7lcw20ayyn
> or
>     bitcoincash8qpzry9x8gf2tvdw0s3jn54khce6mua7lcw20ayyn  (dropping the
> ":")
> or simply
>     8qpzry9x8gf2tvdw0s3jn54khce6mua7lcw20ayyn
>
> An optional long prefix with a mandatory short prefix is good design and
> aids user experience.
>
> Andrew Clifford
> Bitcoin Unlimited
>
> ------------------------------
> *From:* Lucas Clemente Vella via bitcoin-ml <
> bitcoin-ml at lists.linuxfoundation.org>
> *To:* Amaury Séchet <deadalnix at gmail.com>; Bitcoin and related protocol
> coordination <bitcoin-ml at lists.linuxfoundation.org>
> *Sent:* Wednesday, 15 November 2017, 15:03
> *Subject:* Re: [Bitcoin-ml] Proposal to deploy cashaddr January, 14
>
> I agree that is desirable to have a different address format, for the
> reason Amaury explained, but I noticed that the proposed is very similar to
> BIP173. First let me say that I am not convinced about base 32, but more on
> that later.
>
> I could identify two differences from the proposed spec to BIP173:
>  - Separator is ':' instead of '1'
>  - It is valid to omit the prefix
>
> The first difference is so small I don't find it justifiable. I don't
> think it is worth to increase the complexity for implementations that have
> any relation with Bitcoin Segwit just so we can use ':' instead of '1'. For
> instance, Electron Cash is based on Electrum, whose latest version already
> support Bech32 as specified in BIP173.
>
> The second difference is not an improvement, is a setback. It worsens the
> user experience. Since addresses with omitted prefixes are shorter, they
> should see more usage, and users will lose the ability to easily identify
> what currency that address is referring to by simply looking at the string.
> I strongly believe the prefix should be mandatory, and since 'bitcoincash'
> is too long (I assume it was chosen this long because it wouldn't be
> mandatory), I suggest some other smaller string to be used instead, like
> 'bch' or simply 'cs' (from cash) or something of the sort. If the prefix is
> mandatory, them the case for my first point is strengthened: using '1'
> instead of ':' allow me to simply double click the alphanumeric string to
> select it as whole (that is the original reason for using '1', I believe).
>
> So, if we are going to use this proposal at all, I am strongly in favor of
> making it closer to bech32, for the reasons I explained.
>
> That said, I don't like the change from base 58 to base 32, as it is less
> space efficient in ASCII. The choice was a trade-off.
>
> Advantages of base 32 over base 58:
>  - facilitates reading out loud the address (as all letters have the same
> case);
>  - facilitates handwriting down the address (same reason);
>  - Improves space efficiency in QR-Codes by 45%.
>
> Disadvantage:
>  - increases the number of characters by 15% on the most common case of
> P2KH address.
>
> I am mildly against it because 99% of the addresses I interact with are
> written in text, on a screen, and I dislike the aesthetics of big
> horizontal words (and how they can mess up paragraph breaks when inlined
> inside a text).
>
> Is that a good reason? Given how seldom I have to write down addresses (or
> read them aloud), and how current QR-Codes work perfectly fine (and I do
> believe the better alternative would be to simply devise an specific
> encoding for QR-Codes, since they already have error correction), I do
> believe it is a justifiable opposition.
>
> To summarize my position:
>  - Mildly against base 32, prefer old base 58;
>  - Strongly against allowing to drop the prefix from the address, for it
> makes them easier to identify;
>  - As consequence of the above, I am also strongly against using ':'
> instead of '1' as a separator.
>
> I agree with the choice for BCH for error detection, as it seems everybody
> agree it is faster, and no less safer. I don't have an opinion on the
> meaning of the version byte.
>
> 2017-11-14 22:25 GMT-02:00 Amaury Séchet via bitcoin-ml <
> bitcoin-ml at lists.linuxfoundation.org>:
>
> Dear Bitcoin Cash community,
>
> Bitcoin Cash has been in need for a new address format for quite some
> time. There is an immediate problem as people mistakenly send BCH to BTC
> address and vice versa, which is made worse by the fact that segwit on the
> BTC chain had the brilliant idea to leverage outputs that anyone can spend,
> which make the recovery of the funds delicate on the Bitcoin Cash chain.
>
> Because this need is pressing, companies like Bitpay started using
> incompatible addresses format and this is causing fragmentation in the
> Bitcoin Cash ecosystem. I do not wish to blame Bitpay, they took action to
> solve the problem their business faces, this is good business from their
> part.
>
> However, while the problem of funds sent on the wrong chain is pressing,
> there are other reasons we need to update the address format. It is
> imperative that the chosen standard for Bitcoin Cash address the various
> issues present with the current address format as we cannot change
> addresses every other tuesday. The most important one being that current
> outputs are using 160 bits hashes for multiparty contracts such as
> multisig, which is really playing with the limit of what can be considered
> secure. It is also desirable that the format chosen can accommodate new
> features we wish to deploy, or, in other terms, be extensible.
>
> As a result, I propose to upgrade to the cashaddr format. This format ( https://github.com/Bitcoin-
> UAHF/spec/blob/master/ cashaddr.md
> <https://github.com/Bitcoin-UAHF/spec/blob/master/cashaddr.md> ) is based
> on work from Rusty Russel ( https://rusty.ozlabs.org/?p= 578
> <https://rusty.ozlabs.org/?p=578> ) and uses BCH codes in order to ensure
> error detection as suggested by Pieter Wuille for bech32.
>
> Using a new format will prevent users from mistakenly sending money on the
> wrong chain. It also accept payloads up to 512 bits which ensures we can
> deploy more secure way of doing multiparty smart contract in the future.
> Finally, it uses a version field ensuring we can encode new features in
> these addresses in the future without having to use a new format.
>
> In addition of these must have features, cashaddr improve on several
> aspects of current address format in a way that may not justify in itself
> to use a new format, but are nevertheless really nice to have.
>  - It uses a very strong checksum which ensure detection of up to 6 errors
> in an address and 8 in ‘burst’. Larger number of errors have one chance
> over a thousand billion to lead to a valid address.
>  - It encode more compactly in QR codes as it allows the use of the
> alphanumeric mode.
>  - It is much faster to encode and decode than the previous format, which
> is important for system having to handle a large number of addresses.
>
> In order to reduce confusion for users with the use of different
> addresses, I think it is important to deploy this shortly and stop the
> fragmentation of the ecosystem. Deploying such a change on the network will
> take some time for all wallet, exchanges and merchant to upgrade. Christmas
> and new year is coming soon and nobody want to do such an upgrade during
> this time. As a result, I propose we aim for a deployment around Jan, 14 .
> This leaves 2 month for everybody to get ready which I think is reasonable.
> Delaying further would push us into the Chinese new year territory, which
> is also undesirable.
>
> The next version of Bitcoin ABC will include support for cashaddr, hidden
> behind a configuration at first, so people can experiment with it. I would
> like to invite via this message various participants in the ecosystem to do
> the same.
>
> Let's do it ?
>
> Amaury Séchet
>
> ______________________________ _________________
> bitcoin-ml mailing list
> bitcoin-ml at lists. linuxfoundation.org
> <bitcoin-ml at lists.linuxfoundation.org>
> https://lists.linuxfoundation. org/mailman/listinfo/bitcoin- ml
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml>
>
>
>
>
> --
> Lucas Clemente Vella
> lvella at gmail.com
> _______________________________________________
> bitcoin-ml mailing list
> bitcoin-ml at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml
>
>
> _______________________________________________
> bitcoin-ml mailing list
> bitcoin-ml at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml
>
>
> _______________________________________________
> bitcoin-ml mailing list
> bitcoin-ml at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20171115/46d286b5/attachment-0001.html>