[Bitcoin-ml] bitcoin-ml Digest, Vol 6, Issue 18

Duzy Chan geek at duzy.info
Wed Nov 15 00:54:25 UTC 2017


On Wed, Nov 15, 2017 at 8:39 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
>         https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml
> 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. Proposal to deploy cashaddr January, 14 (Amaury S?chet)
>    2. Re: Proposal to deploy cashaddr January, 14
>       (Blockfreight? | Julian Smith)
>    3. Re: Proposal to deploy cashaddr January, 14 (checksum0)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 15 Nov 2017 01:25:50 +0100
> From: Amaury S?chet <deadalnix at gmail.com>
> To: Bitcoin and related network protocol discussion
>         <bitcoin-ml at lists.linuxfoundation.org>
> Subject: [Bitcoin-ml] Proposal to deploy cashaddr January, 14
> Message-ID:
>         <
> CANGV3T0ERYQ5NuBcx9CRmMpjcO8S4PNDb3TxdtjE-AbFyk_qDQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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.
>

DON'T DON'T DON'T do it!! Bitcoin Cash never require a new address scheme!!
It's NEVER been a mistake to use the same address for BTC, BCH, or other
forks! It's very interesting that you're trying to classify the BTC and BCH
by address. The fact that one Bitcoin address is holding multiple assets
have already long history. If one owns an address, it won't cause any fund
losses. What kind of idea have made you think that the BCH needs a new
address scheme???


>
> 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 ) 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 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20171115/4afb9119/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Wed, 15 Nov 2017 11:32:53 +1100
> From: Blockfreight? | Julian Smith      <julian.smith at blockfreight.com>
> To: Amaury S?chet <deadalnix at gmail.com>,        Bitcoin and related
> protocol
>         coordination    <bitcoin-ml at lists.linuxfoundation.org>
> Subject: Re: [Bitcoin-ml] Proposal to deploy cashaddr January, 14
> Message-ID:
>         <
> CAKCGAO8uemPT-ke-DWHjoA_LJuhCmhpq5JFyLKsGKaYtQYP+tw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Fuck no let's not.
>
> Bitcoin addresses work.
>
> This isn't useful.
>
> On Wed, Nov 15, 2017 at 11:25 AM, 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
> 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 ) 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
> 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
> > 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/1ec7051e/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Tue, 14 Nov 2017 19:39:33 -0500
> From: checksum0 <checksum0 at protonmail.com>
> To: Amaury S?chet <deadalnix at gmail.com>
> Cc: Bitcoin and related network protocol discussion
>         <bitcoin-ml at lists.linuxfoundation.org>
> Subject: Re: [Bitcoin-ml] Proposal to deploy cashaddr January, 14
> Message-ID:
>
> <YsfmURakesIGlMpgzrE2GEPu5GPZ4JK_CO-PZ4FGaA6B6JMMXmGoGIwh4idaqgaJDIrkInfHVoiXoDKcaVLh3SodveyWek9FBmpmZf9EPIQ=@
> protonmail.com>
>
> Content-Type: text/plain; charset="utf-8"
>
> Let's definitely do this. Changing the address prefix is easy however the
> larger payloads as well as stronger checksum capability is a must.
>
> Let's move quickly like only the Bitcoin Cash community can do.
>
> P.S.: Please let's not have the knee jerk reaction of judging bech32 over
> it's perceived association with segwit.
>
> > -------- Original Message --------
> > Subject: [Bitcoin-ml] Proposal to deploy cashaddr January, 14
> > Local Time: November 14, 2017 7:25 PM
> > UTC Time: November 15, 2017 12:25 AM
> > From: bitcoin-ml at lists.linuxfoundation.org
> > To: Bitcoin and related network protocol discussion <
> 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 ) 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 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20171114/4a7dc5d2/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> bitcoin-ml mailing list
> bitcoin-ml at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml
>
>
> End of bitcoin-ml Digest, Vol 6, Issue 18
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20171115/f480d0d5/attachment-0001.html>


More information about the bitcoin-ml mailing list