1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
|
Return-Path: <admin@glados.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id ABB40F38
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 28 Aug 2015 15:27:02 +0000 (UTC)
Received: by ykdz80 with SMTP id z80so18668335ykd.0
for <bitcoin-dev@lists.linuxfoundation.org>;
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: <CAL7-sS3CaHvZxUb-Q6HagHYufYnko_T4TBoFhd31rr5OxaiAEw@mail.gmail.com>
References: <CAL7-sS2mrBqM7w5T8mRBFvVrCaHy1zT1YsgrHUxRBqdTFqczow@mail.gmail.com>
<CAL7-sS3CaHvZxUb-Q6HagHYufYnko_T4TBoFhd31rr5OxaiAEw@mail.gmail.com>
Date: Sat, 29 Aug 2015 01:27:01 +1000
Message-ID: <CAL7-sS1aMqrUzMEbiQUWuxFtVHGv+-is7-BeAuje3rfQs_-JeQ@mail.gmail.com>
From: gladoscc <admin@glados.cc>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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
<p dir=3D"ltr">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. </p>
<p dir=3D"ltr">I propose identifying blockchains for BIP 21 and any other r=
elevant needs through:</p>
<p dir=3D"ltr">1) the genesis block hash for a new chain, or<br>
2) a hash of the genesis block hash,=C2=A0 concatenated with block hash(es)=
of fork point(s) for a fork chain</p>
<p dir=3D"ltr">This would support forks, forks of forks, forks of forks of =
forks, etc while preserving a fixed length chain identifier.</p>
<p dir=3D"ltr">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. </p>
<p dir=3D"ltr">Thoughts? </p>
--001a11397c7a1d6971051e60b7b2--
|
