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 ABB40F38 for ; Fri, 28 Aug 2015 15:27:02 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yk0-f177.google.com (mail-yk0-f177.google.com [209.85.160.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3FFA6230 for ; Fri, 28 Aug 2015 15:27:02 +0000 (UTC) Received: by ykdz80 with SMTP id z80so18668335ykd.0 for ; Fri, 28 Aug 2015 08:27:01 -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:content-type; bh=pVCBYZ3tWY1ljGGyuID/b2KINSu+csks/FHuX1DOYIw=; b=GaDI+tZ2Z6f1I4nq6nGg/aHr9PMeqIbDo+FGyaHHEsCx1T/5hEy92YDYrr5igNSWUG Aev7uztqq8PNmHNPf1OTvJye8A1LyzShpqVqZroYB9JikGIkPIkDffVoIsA7eeUAn0HY Vl4lDjoAGcKOPxXzKJUMg9PgK7/SnVKS/SZtXmRbAGwzWyJrEvnwmvmH1gRMDDn4iqEL D8r6AYanODZW/1MHdysnjeNsoZVSv6EBL0EKm1bIUertiUsTrffSF8wfA50erQH9y8F0 mvT5ioBVkP2kyVHAFaenm/VEq6QLH7ji76u6inA4tbcuRWxT52KXuuL6YbtxfUmVL4TV xocw== X-Gm-Message-State: ALoCoQnFjSVyhdlt2LglGOFaHkgvaUcX67Dqcl+50cKtuiWjGdSruYBZplA4MFu68NS0E42wB61d MIME-Version: 1.0 X-Received: by 10.170.185.20 with SMTP id b20mr3174748yke.30.1440775621389; Fri, 28 Aug 2015 08:27:01 -0700 (PDT) Received: by 10.37.53.2 with HTTP; Fri, 28 Aug 2015 08:27:01 -0700 (PDT) X-Originating-IP: [211.30.212.14] Received: by 10.37.53.2 with HTTP; Fri, 28 Aug 2015 08:27:01 -0700 (PDT) In-Reply-To: References: Date: Sat, 29 Aug 2015 01:27:01 +1000 Message-ID: From: gladoscc To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a11397c7a1d6971051e60b7b2 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, 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 Subject: [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 15:27:02 -0000 --001a11397c7a1d6971051e60b7b2 Content-Type: text/plain; charset=UTF-8 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? --001a11397c7a1d6971051e60b7b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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 genesi= s 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 sy= stems redundantly.

I propose identifying blockchains for BIP 21 and any other r= elevant needs through:

1) the genesis block hash for a new chain, or
2) a hash of the genesis block hash,=C2=A0 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 longe= st with PoW", they would use (1). In times where multiple chains are c= oexisting and being actively mined, a user can use (2) to specifically iden= tify a chain.

Thoughts?

--001a11397c7a1d6971051e60b7b2--