From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1EB9B1398 for ; Tue, 1 Sep 2015 23:57:19 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 410C8177 for ; Tue, 1 Sep 2015 23:57:18 +0000 (UTC) Received: by wibz8 with SMTP id z8so48100286wib.1 for ; Tue, 01 Sep 2015 16:57:17 -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=/lBeptb8hCoarJiAOhhlJJyzYTkWw1ahx+yRakHRk9w=; b=GNWVWmpBQnosX6F2APZ1qmbmawCwgpnrxqSPqO6k3JQw7Y3yN2+VIHIjK8m6kOy0ng 5bajT+i5fn6PM1BZBvxSTrWT4rLxNgxBZ/BYosO1wo8wtQqv4r8tHl6is4Lw0IUU3QUx XoUusQ4iyf3/iE7Emp3hudIy/9SpWej4xLqYqB16YNFQ7JUEwd95H5DYZo4xlAUpEbcG /tjLo6qVuZGcVqvlttWnfBMJHaUe9RuCS7Lxyrf+DIygnMusNkHxWMTQZw6S0Zb9Bsob QTvSGiTlqid194IU4M3Z8x/N8xYuyDbeecTp6sEqysdL+Mgq/jUTFP5oF44yX1dx/irf d3Xw== X-Gm-Message-State: ALoCoQmhiBZY9rgw2oGguSKbpjyvWnCCCI1TVnJZ8TuBJIrCIfUy8i44UNeExmYBSwV4Cq0pspzH MIME-Version: 1.0 X-Received: by 10.194.122.97 with SMTP id lr1mr36229939wjb.26.1441151836870; Tue, 01 Sep 2015 16:57:16 -0700 (PDT) Received: by 10.194.234.197 with HTTP; Tue, 1 Sep 2015 16:57:16 -0700 (PDT) In-Reply-To: References: <2509151.XgrrNGsCxR@crushinator> Date: Wed, 2 Sep 2015 01:57:16 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Btc Drak 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 , Matt Corallo Subject: Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration 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: Tue, 01 Sep 2015 23:57:19 -0000 On Wed, Sep 2, 2015 at 12:56 AM, Btc Drak wrote: > When I brought up the issue originally, I deliberately steered away > from altchains choosing to focus on networks like mainnet, testnet > because I think it's easier to repurpose a protocol for an altcoin > than it is to make the proposal work for all cases. Take the payment > protocol for example. The BIP specifies a URI with bitcoin: well it's > just as easy to repurpose that for litecoin: etc than adding something > like ?cointype=3Dlitecoin, so that was my reason for not mentioning > altcoins at all. > > If the proposal is made to account for altcoins, genesis hash is > definitely not desirable, or at least not genesis hash in isolation, > and if that's the case, better to have an identifier I agree. That's why we don't need to account for altchains other than testchains (ie sidechains and altcoins). > On Sun, Aug 30, 2015 at 3:20 AM, Jorge Tim=C3=B3n > wrote: >>> Some altcoins (LTC and FTC for example) have the same genesis block has= h. >> >> That's obviously a design mistake in FTC, but it's not unsolvable. FTC c= ould >> move their genesis block to the next block (or the first one that is not >> identical to LTC's). >> >> Bitcoin and all its test chains have different genesis blocks, so I'm no= t >> sure FTC should be a concern for a BIP anyway... > > That's a very sweeping generalisation indeed. Why should two chains > have to have a separate genesis? It's cleaner, but it's certainly not > a necessity. You cant exclude this case just because it doesn't fit > your concept of neat and tidy. Other BIP proposals that account for > alternative chains do not rely on the genesis hash, but instead an > identifier. Why should it be any different here? On Wed, Sep 2, 2015 at 12:59 AM, Btc Drak wrote: > The only sane way to me see to have cointype like BIP44. > See https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#coin-t= ype We can do it the right way from now on (and as you say altcoins can trivially adapt to this). Sorry for having missed bip44 for review but that section is horrible in my opinion (see the links above). And it seems to be incompatible with bip001 which says are immutable once accepted (assuming that document is expected to be the central registry of registered chains). > How would you account > for a world with XTCoin and Bitcoin which would also share the same > genesis hash, but clearly not be the same coin. Schism hardforks are explicitly renouncing to reach consensus with all previous users. You're intentionally divorcing 2 chains, and you can do that without confusing users. In BIP99 the recommended deployment path for a schism fork is to simply use the nHeight for activation. The 95% miner's upgrade confirmation is not used here (like in uncontroversial hardforks and softforks) because you don't necessarily expect all miners to move to your side of the schism (and you don't want to wait for them, specially if it's an "anti-miner" hardfork). To avoid confusing users, you can define a new "genesis block" to use for the chain ID, for example, 1000 blocks before the activation height. The same applies for potentially pre-mined altcoins that haven't had the decency/competency of even changing the string in pszTimestamp. For example, FTC, coins generated with coingen (Matt Corallo or the current owner may want to correct me on this point) or elements alpha (https://github.com/ElementsProject/elements/blob/alpha/src/chainparams.cpp= #L115). Fortunately alpha has a unique chain ID because it was changing both the block and transaction serialization formats anyway. But hopefully we will fix that for beta and later sidechains. All chains that want a unique chain ID can have it retroactively. At worst, they may need to use the hash of a block that is not the genesis block. In other words, they may need to move their "genesis checkpoint" upwards. Terminology may make things more clear. We can replace: "The chain ID is the hash of the genesis block" with "The chain ID is the hash of the genesis checkpoint". If we want a unique chain ID we can have it: it just cannot be memorable at the same time. And each chain and implementation can start using them (in addition to petname -> chain ID local dictionaries) at any point in time: this is retroactively (and obviously forwards) compatible. There can be many competing registries for the name -> chainID dictionaries (maybe one of them based on namecoin?) but bitcoin/bips shouldn't maintain one.