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