Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id ABEC5BCC for ; Sun, 6 Sep 2015 02:09:54 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E7C1B126 for ; Sun, 6 Sep 2015 02:09:53 +0000 (UTC) Received: by wiclk2 with SMTP id lk2so55433783wic.0 for ; Sat, 05 Sep 2015 19:09:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Ue/ONBjfdAv7WT55pMVXVlBXUFlxK0JjbhJ3fZ98rac=; b=KP9s2xGTwEjsBo/90GH6wQm+GH5r023G+Ki4ZJK1BG4e6EabZfifp/PuOmjIe/I8Bl udn9Lf0O6XlZI7F4+g8dPwhOZgBj6GyXIVr3tNjESmRxhs40ittyTbuVY0IJJV0NVVgZ FOT4nNodj/W58FMHsB5IOAE2gAf3a+9t7mQiEGNd6mGc2Rd32qZQaT86zgVNlZydiDbI mI+sylWnuUpHmcc+DuqdrHwNwWlSInv6BjSWGlvb1w6G5HNg124a4X/rQafbsnFw1Yfo H20p+isH8e1JRdfEvNmLIgk8YJ7ss34gW1qNI7brHwKtaCuLwiyyZr/mnzBQcbYXH/zq 64bg== X-Gm-Message-State: ALoCoQkdQDhU3tS7OGuBHYVa7l3Z2xLBrxWeDlZbceRwtMlSQ4hqd7gTHAxWU0+3ZxPM+FbKRj3r MIME-Version: 1.0 X-Received: by 10.180.105.74 with SMTP id gk10mr20724469wib.92.1441505392522; Sat, 05 Sep 2015 19:09:52 -0700 (PDT) Received: by 10.194.37.5 with HTTP; Sat, 5 Sep 2015 19:09:52 -0700 (PDT) In-Reply-To: References: <201509040006.06430.luke@dashjr.org> <55E9D980.5020901@openbitcoinprivacyproject.org> Date: Sun, 6 Sep 2015 04:09:52 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Christophe Biocca Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] RFC: HD Bitmessage address derivation based on BIP-43 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2015 02:09:54 -0000 On Sat, Sep 5, 2015 at 6:48 PM, Christophe Biocca wrote: > I will point out that the current situation is not an accident: > https://github.com/bitcoin/bips/pulls?utf8=3D%E2%9C%93&q=3D44 is a great > place to get some context for what happened. I believe you can also > find the other half of this discussion on the mailing list archives. > > The cointypes being simple integers was how the code worked as shipped > (in the trezor), so changing the semantics after the fact wasn't a > possibility. > > The BIP repository didn't want to constantly deal with updates > unrelated to Bitcoin proper, so a decision was made to move that part > of the standard to a repository willing to handle it. This is in fact useful. The centralized registries themselves are fine provided that we don't rely on having only one of them or in them having the same values for the same chains. Trezor can maintain its own too. Future versions of Trezor could support full chain IDs instead of these integers (or keep using these integers forever, whatever they chose to do). On Sat, Sep 5, 2015 at 7:03 PM, Luke Dashjr wrote: > On Saturday, September 05, 2015 11:17:52 AM Jorge Tim=C3=B3n via bitcoin-= dev wrote: >> The "namespace" defined in BIP43 is acceptable. BIP44's is not: >> >> https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#Registere= d_c >> oin_types >> >> It defines a centralized registry controlld by a single company instead = of >> having a way for different companies (or p2p chains like namecoin?) to >> maintain competing registries. >> >> Even better, it could use a code deterministically generated from the ch= ain >> ID (the hash of the genesis block), completely removing the need for a >> registry in the first place. > > No, because different chains may very well use the same genesis block. Can you read my reasoning here? http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/01086= 1.html What I propose is retro-compatible, even for carelessly designed chains (that allowed pre-mining) like FTC. And provides securely unique IDs that don't require a centralized registry. Maybe I should start a Chain IDs BIP...