[Bitcoin-ml] bitcoin-ml Digest, Vol 6, Issue 36
geek at duzy.info
Sat Nov 18 02:57:42 UTC 2017
I'm so concerned about the CashAddr (
https://github.com/Bitcoin-UAHF/spec/blob/master/cashaddr.md). By quickly
reading it, it seems to be the idea of "bitcoincash:" scheme and checksum.
I'm having questions, wish you guys don't mind to have a look.
*Is the CashAddr compatible with Bitcoin Address at some level?* By
compatible, I mean a CashAddr can be converted into Bitcoin Address
(ClassicAddr) which is available to receive BTC, in this case the
ClassicAddr and CashAddr shares the same private key.
The reason why I'm so concerned and asking is that having one private key
to control multiple assets like BTC+BCH is very cool feature!
So if a CashAddr and CassicAddr is compatible at some level, like sharing
the same private key, thus one can generate a CashAddr or ClassicAddr on
his behave. Or if better, a CashAddr can be directly converted into
ClassicAddr or vise versa. Then the idea of CashAddr will be great!
On Fri, Nov 17, 2017 at 8:27 AM <
bitcoin-ml-request at lists.linuxfoundation.org> wrote:
> Send bitcoin-ml mailing list submissions to
> bitcoin-ml at lists.linuxfoundation.org
> To subscribe or unsubscribe via the World Wide Web, visit
> or, via email, send a message with subject or body 'help' to
> bitcoin-ml-request at lists.linuxfoundation.org
> You can reach the person managing the list at
> bitcoin-ml-owner at lists.linuxfoundation.org
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-ml digest..."
> Today's Topics:
> 1. Re: Proposal to deploy cashaddr January, 14 (Amaury S?chet)
> 2. Re: Proposal to deploy cashaddr January, 14 (Bitcartel Software)
> Message: 1
> Date: Thu, 16 Nov 2017 22:30:16 +0100
> From: Amaury S?chet <deadalnix at gmail.com>
> To: Jason Dreyzehner <jason at dreyzehner.com>
> Cc: Bitcoin and related protocol coordination
> <bitcoin-ml at lists.linuxfoundation.org>
> Subject: Re: [Bitcoin-ml] Proposal to deploy cashaddr January, 14
> CANGV3T3Hyvxj86HsUVeivbZe7Jc1sC1N4hE9YgDXDCVSRKasRw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> The use of ":" is due to the fact that it is what's used in link and/or QR
> codes already. Choosing something else means that you need to double
> prefix. Because the prefix is checksumed, it can actually be implicit in
> most cases and only be specified when there is an ambiguity. Let me
> explicit. In a QR code, you would encode:
> >From the bitcoincash prefix, your QR code reader determine that it needs
> be open with your bch wallet. The bch wallet receive the address
> "abcdefwhateverchecksum" . If that address is not a bitcoincash address,
> then the checksum will be invalid and the wallet can reject it. That means
> that in most cases, the prefix is just implicit.
> Because the prefix is implicit, there is no need to make it especially
> short. in fact, because it need to designate bitcoin cash in some global
> namespace, it needs to be long enough to avoid name clashes.
> So we get to a) it doesn't matter if the prefix get dropped and b) it
> doesn't matter if the prefix gets dropped :) In both cases, the prefix is
> implied in the checksum. Only put the prefix in case you need to
> deambiguate, or when embedding in a link/QR code.
> For unknown version byte, the wallet should reject. Longer term it is
> desirable to move to a (version, hash) output, and I hope to convince
> people this is the right thing to do - that'd make the protocol much more
> upgradable. But we'll see how that one goes.
> For error correction, I have code for it in C++ that I used to research
> what's the best BCH codes to be used given the criterion. It rathe raw but
> I can put it in shape if this is something people want. However, I would
> advice against trying to do error correction on addresses. While you can
> detect 6 errors with the chosen code, you can only correct 3. If you have
> more than 3, you will correct incorrectly, sending the funds in a black
> hole. The basic idea is that you compute the checksum for a vector of 0
> (without starting and ending with a 1 in the buffer as it is done for the
> checksum) except for one character. The checksum that you get is what the
> final checksum will be xored with if the character you changed is invalid
> by the value you changed. Once you compute all the checksums for all the
> possible errors, you can use gaussian elimination to find out what set of
> errors can be applied to get a valid address. It sounds complicated, but
> for 1 or 2 errors, it is really easy. For 3 it's a bit more tricky, but
> nothing extraordinary.
> For the birthday solution, this is indeed an option to solve it. Or going
> with version, hash as an output. Whichever gets traction.
> 2017-11-16 6:13 GMT+01:00 Jason Dreyzehner <jason at dreyzehner.com>:
> > Thanks for your work on this Amaury! I?m excited about this format and
> > definitely think it?s a step forward. I also appreciate the goal of
> > committing to a rollout schedule, at least for the most
> > implementations.
> > *Questions on the spec*:
> > *Design considerations*: could you provide your reasoning where this spec
> > differs from BIP 173? I?m most interested in: a) the use of `:` rather
> > `1`, and b) your reasoning for choosing slightly longer standard prefixes
> > (`bitcoincash`, `xbctest`).
> > For (a), this eliminates the double-click select-ability on most OSes.
> > essential, but if the design goal is clear separation, did you consider
> > use of the period character (`.`)? Still not selectable on Windows, but
> > works for macOS and some Linux users. (I see that both are also within
> > alphanumeric mode character set for the QR Code standard.) BIP 173 uses a
> > `1`, which guarantees select-ability across all environments, and
> > also would reduce the chance of humans mistakenly copying only the hash
> > checksum. (Esp. those humans already accustomed to other crypto
> > For (b) ? the test vector
> > is 52 characters, 11 of which indicate the network. This is fairly
> > expensive, and completely precludes the use of Version 2 L QR Codes (max
> > Alphanumeric). In this case, with a prefix of 6 characters or shorter, we
> > can save a level of QR complexity.
> > *Future compatibility*: can this spec provide guidance on how
> > implementations should handle unknown version bytes?
> > *Error correction*: is there a sample implementation which
> > properly/safely demonstrates error correction?
> > *P2SH birthday attack resistance*: is there a proposed implementation for
> > this? In your vision, does this expand the current BIP 16 P2SH mechanism
> > include a new script template? (e.g. `OP_HASH256 [32-byte-hash-value]
> > OP_EQUAL`) Or does it rely on a new mechanism? 
> > *On the rollout schedule*:
> > It seems like a great goal to have ecosystem-wide support by Jan 14.
> > It?s probably also worthwhile to derive some lessons from the rollout of
> > BIPs 70-73: until we have almost universal support, the
> > costs of making a new address format ?default? for any consumer product
> > seems to be quite high.
> > For example, in a limited rollout of ?on-by-default? BIP 73 support,
> > BitPay found that a surprising percentage of users contacted BitPay?s
> > support when their outdated wallets weren?t able to parse the simpler QR
> > code. (Logically, since the users had used their wallet before, they
> > perceive the problem to be with the receiving QR code.) Even with further
> > development (including an adjacent, primary call to action of ?QR code
> > scanning?? and other attempts at educating users), it simply wasn?t
> worth a
> > wider rollout.
> > *Rollout phases*: To avoid that unnecessary cost, I?d recommend we break
> > rollout into two phases: ?implementation? in January (assuming
> > agree on this spec), and a later rollout date for ?on-by-default support?
> > (like March or April). This lowers the stakes for companies with
> > priorities, since they?ll have a number of weeks to verify adequate
> > ecosystem support before completely committing.
> > *In the meantime*, it would also be a good idea for implementations still
> > using the old `1` and `3` address formats to upgrade to the address
> > adopted by Copay (https://bitpay.github.io/address-translator/). I know
> > it?s easy for many of us to believe that users can keep old-format
> > addresses straight between the networks, but please keep in mind ?
> > an astoundingly large group of users who believe BCH and BTC are
> > interchangeable because ?it let me send it??
> > : My preference would be to implement this using Bitcoin Script by
> > defining one of the extensible OP_NOPs to ?OP_CHECKREDEEMSCRIPT?. (Rather
> > than another BIP 16-style ?magic template?.)
> > Jason
> > On Tue, Nov 14, 2017 at 7:26 PM Amaury S?chet via bitcoin-ml <
> > bitcoin-ml at lists.linuxfoundation.org> wrote:
> >> 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
> >> BTC chain had the brilliant idea to leverage outputs that anyone can
> >> 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
> >> 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
> >> 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 ) is based
> >> on work from Rusty Russel ( https://rusty.ozlabs.org/?p=578 ) and uses
> >> BCH codes in order to ensure error detection as suggested by Pieter
> >> 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
> >> 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,
> >> 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
> >> take some time for all wallet, exchanges and merchant to upgrade.
> >> 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
> >> Delaying further would push us into the Chinese new year territory,
> >> is also undesirable.
> >> The next version of Bitcoin ABC will include support for cashaddr,
> >> behind a configuration at first, so people can experiment with it. I
> >> 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
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> Message: 2
> Date: Thu, 16 Nov 2017 16:27:06 -0800
> From: Bitcartel Software <simon at bitcartel.com>
> To: Amaury S?chet <deadalnix at gmail.com>, Bitcoin and related
> coordination <bitcoin-ml at lists.linuxfoundation.org>
> Subject: Re: [Bitcoin-ml] Proposal to deploy cashaddr January, 14
> rqVbt2r7R2mqkX+aFMvBn+fNVX0c93w at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
> Hi everybody,
> I would like to propose reserving a few extra bytes as part of either
> (a) address type, or (b) the payload.
> This would help future-proof the address format for new features which
> wallets can choose to implement.
> How these bytes are used can be specified by the community at a later date.
> One example is address flags.
> As implemented in the CoinSpark colored coin protocol, address flags
>  help sending wallets know what
> features the recipient's wallet supports.
> For example, if the sender is transferring OP_RETURN based assets, the
> sending wallet will verify that the
> recipient's address supports assets, to avoid a non-supporting wallet
> from accidentally sending on those assets.
> Another example is a feature like out-of-band messaging, where not all
> wallets support messaging, so the
> sending wallet would only enable the message UI field if the recipient
> address indicated it supported messages.
>  https://coinspark.org/developers/coinspark-addresses/
> Best Regards,
> On Tue, Nov 14, 2017 at 4:25 PM, Amaury S?chet via bitcoin-ml
> <bitcoin-ml at lists.linuxfoundation.org> wrote:
> > Dear Bitcoin Cash community,
> > Bitcoin Cash has been in need for a new address format for quite some
> > There is an immediate problem as people mistakenly send BCH to BTC
> > and vice versa, which is made worse by the fact that segwit on the BTC
> > had the brilliant idea to leverage outputs that anyone can spend, which
> > the recovery of the funds delicate on the Bitcoin Cash chain.
> bitcoin-ml mailing list
> bitcoin-ml at lists.linuxfoundation.org
> End of bitcoin-ml Digest, Vol 6, Issue 36
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitcoin-ml