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 E6F3DD44 for ; Fri, 28 Aug 2015 20:15:43 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [69.252.207.35]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7FF20152 for ; Fri, 28 Aug 2015 20:15:43 +0000 (UTC) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-03v.sys.comcast.net with comcast id ALFi1r0022Ka2Q501LFiDJ; Fri, 28 Aug 2015 20:15:42 +0000 Received: from crushinator.localnet ([IPv6:2601:186:c000:825e:e9f4:8901:87c7:24a0]) by resomta-ch2-11v.sys.comcast.net with comcast id ALFh1r00D4eLRLv01LFhMb; Fri, 28 Aug 2015 20:15:42 +0000 From: Matt Whitlock To: gladoscc Date: Fri, 28 Aug 2015 16:15:40 -0400 Message-ID: <2081350.pl7B3yspcG@crushinator> User-Agent: KMail/4.14.10 (Linux/4.0.5-gentoo; KDE/4.14.11; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1440792942; bh=2EDHLZT4jAvS6N19jz/uhUF5bGJOqwRqpgzxzJ0Ekdo=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=AZXzK7WMPs4NTP4ahYy9ZHDIiOfyyv3Zc/EWBCoZ42KHYDcnidGInLThmF3he3Fys H2TXN4LP11zxAt2LU2vI4qT255nx1aW1JgsC6RYgFRivZVJsyGhV95zHumaE3yIcLG 5I8eBRZ0jF/JRYAB7WAOgOzRix/4ZzaEZc8v9QFKkQbdJEPYw1KDO2Ys8zaHpQUnc1 LIgM6U6P3fhqn/v+osbTxeflGaqs0Y1GXm11rvkAoaLwzjM2TGx8f+x0UHEcgufoP/ 3DCiaiipMw/5s8A/t5Rk9llLDcTZMsexoILsBPGkmMcnkAH9nRa8q1MDOCxogtikAS jJLCnKloZhO0A== X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE 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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Uniquely identifying forked chains 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: Fri, 28 Aug 2015 20:15:44 -0000 Why would you use a hash of hashes? Wouldn't it be simpler and just as effective to use either: 1) the genesis block hash, or 2) the block hash of the first block in a fork? Every block hash in a chain implicitly subsumes the genesis block hash of that chain, so there's no need to incorporate the genesis block hash again. On Saturday, 29 August 2015, at 1:27 am, gladoscc via bitcoin-dev wrote: > There has been discussion of using the genesis block hash to identify > chains in BIP 21 (bitcoin:// URI scheme). However, this does not allow > identification between blockchain forks building upon the same genesis > block. While many see this as undesirable, I think it is inevitable that > this will eventually happen at some point, and think it is best to build > systems redundantly. > > I propose identifying blockchains for BIP 21 and any other relevant needs > through: > > 1) the genesis block hash for a new chain, or > 2) a hash of the genesis block hash, concatenated with block hash(es) of > fork point(s) for a fork chain > > This would support forks, forks of forks, forks of forks of forks, etc > while preserving a fixed length chain identifier. > > If a user wants to specify "whatever chain is the longest with PoW", they > would use (1). In times where multiple chains are coexisting and being > actively mined, a user can use (2) to specifically identify a chain. > > Thoughts?