summaryrefslogtreecommitdiff
path: root/68/3675a34b3607f20b0662db78e814ce568432c2
blob: 22de69680285736c7c0bb4f4980525fedd43a6ff (plain)
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
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
Return-Path: <jrn@jrn.me.uk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 7BDAF9A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  9 Aug 2015 16:23:31 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from homiemail-a3.g.dreamhost.com (homie.mail.dreamhost.com
	[208.97.132.208])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id 53EE01B9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  9 Aug 2015 16:23:30 +0000 (UTC)
Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id AC32D28408C;
	Sun,  9 Aug 2015 09:23:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=jrn.me.uk; h=subject:to
	:references:cc:from:message-id:date:mime-version:in-reply-to:
	content-type; s=jrn.me.uk; bh=QdBZwKyogpEjMm39tXCiXDXz5FI=; b=p7
	2VSiiVRJjPVyC39h5K7m6C7U4cVsGiclhueydUTaGG5m0CVFyBwSLDfxxdQA8SQ3
	+A9ThMmdwnFa/CKOFv78BQPHAn6UnseTe87oLD245TCN17ej8Gh+zQpc5NmTvgKe
	ds16wodf6W5TvjC1q4Ws9Zx8MSCjTyny0azGytIuA=
Received: from [10.9.1.130] (unknown [89.238.129.18])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: jrn@jrn.me.uk)
	by homiemail-a3.g.dreamhost.com (Postfix) with ESMTPSA id 1D5A328406A; 
	Sun,  9 Aug 2015 09:23:28 -0700 (PDT)
To: Mike Hearn <hearn@vinumeris.com>
References: <55C75FC8.6070807@jrn.me.uk>
	<CA+w+GKS4O176C4-oGw913xvNSXzaBPO-UpU3SrzWR2yE-gcTwQ@mail.gmail.com>
From: Ross Nicoll <jrn@jrn.me.uk>
Message-ID: <55C77E80.3060203@jrn.me.uk>
Date: Sun, 9 Aug 2015 17:23:28 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
	Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <CA+w+GKS4O176C4-oGw913xvNSXzaBPO-UpU3SrzWR2yE-gcTwQ@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------000707080009060206010200"
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Alternative chain support for payment protocol
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: Sun, 09 Aug 2015 16:23:31 -0000

This is a multi-part message in MIME format.
--------------000707080009060206010200
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

I'm cautious of using human-meaningful identifiers, especially any that 
might require a central repository, due to name collisions. Examples 
that could be complicated include BitcoinDark, Litedoge, and other names 
that base on existing coins. I think the ability to differentiate 
between test networks is also useful.

Could certainly just use the genesis hash as network ID, that would 
work. Bit long, but suspect 64 bytes isn't the end of the world! I'll 
see if any more responses come in then raise a BIP for using genesis 
hash as an alternative to short names.

Ross

On 09/08/2015 15:29, Mike Hearn wrote:
>
>     I'd appreciate initial feedback on the idea, and if there's no
>     major objections I'll raise this as a BIP.
>
>
> The reason BIP 70 doesn't do this is the assumption that alt coins are 
> ... well .... alt. They can vary in arbitrary ways from Bitcoin, and 
> so things in BIP70 that work for Bitcoin may or may not work for other 
> coins.
>
> If your alt coin is close enough to BIP 70 that you can reuse it "as 
> is" then IMO we should just define a new network string for your alt. 
> network = "dogecoin-main" or whatever.
>
> You could also use the genesis hash as the network name. That works 
> too. But it's less clear and would involve lookups to figure out what 
> the request is for, if you find such a request in the wild. I don't 
> care much either way.


--------------000707080009060206010200
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    I'm cautious of using human-meaningful identifiers, especially any
    that might require a central repository, due to name collisions.
    Examples that could be complicated include BitcoinDark, Litedoge,
    and other names that base on existing coins. I think the ability to
    differentiate between test networks is also useful.<br>
    <br>
    Could certainly just use the genesis hash as network ID, that would
    work. Bit long, but suspect 64 bytes isn't the end of the world!
    I'll see if any more responses come in then raise a BIP for using
    genesis hash as an alternative to short names.<br>
    <br>
    Ross<br>
    <br>
    <div class="moz-cite-prefix">On 09/08/2015 15:29, Mike Hearn wrote:<br>
    </div>
    <blockquote
cite="mid:CA+w+GKS4O176C4-oGw913xvNSXzaBPO-UpU3SrzWR2yE-gcTwQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">I'd
              appreciate initial feedback on the idea, and if there's no
              major objections I'll raise this as a BIP.<br>
            </blockquote>
            <div><br>
            </div>
            <div>The reason BIP 70 doesn't do this is the assumption
              that alt coins are ... well .... alt. They can vary in
              arbitrary ways from Bitcoin, and so things in BIP70 that
              work for Bitcoin may or may not work for other coins.</div>
            <div><br>
            </div>
            <div>If your alt coin is close enough to BIP 70 that you can
              reuse it "as is" then IMO we should just define a new
              network string for your alt. network = "dogecoin-main" or
              whatever.</div>
            <div><br>
            </div>
            <div>You could also use the genesis hash as the network
              name. That works too. But it's less clear and would
              involve lookups to figure out what the request is for, if
              you find such a request in the wild. I don't care much
              either way.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>

--------------000707080009060206010200--