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
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
|
Return-Path: <giannis@coinomi.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 77FAF7AD
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Aug 2015 18:57:40 +0000 (UTC)
X-Greylist: delayed 00:15:22 by SQLgrey-1.7.6
Received: from sender163-mail.zoho.com (sender1.zohomail.com [74.201.84.158])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C004F1C9
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Aug 2015 18:57:39 +0000 (UTC)
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com
[209.85.212.170]) by mx.zohomail.com
with SMTPS id 1439145734800576.0316274005589;
Sun, 9 Aug 2015 11:42:14 -0700 (PDT)
Received: by wicne3 with SMTP id ne3so111704343wic.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 09 Aug 2015 11:42:12 -0700 (PDT)
Received: by 10.28.48.141 with HTTP; Sun, 9 Aug 2015 11:42:12 -0700 (PDT)
Received: by 10.28.48.141 with HTTP; Sun, 9 Aug 2015 11:42:12 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.74.148 with SMTP id t20mr17521320wiv.31.1439145732905;
Sun, 09 Aug 2015 11:42:12 -0700 (PDT)
In-Reply-To: <CADv+LCxF5MoSFcCiqXnXXsfE5KvJmL0RQ4pOhmM-5eb2TH-ncg@mail.gmail.com>
References: <55C75FC8.6070807@jrn.me.uk>
<CA+w+GKS4O176C4-oGw913xvNSXzaBPO-UpU3SrzWR2yE-gcTwQ@mail.gmail.com>
<55C77E80.3060203@jrn.me.uk>
<CADv+LCxF5MoSFcCiqXnXXsfE5KvJmL0RQ4pOhmM-5eb2TH-ncg@mail.gmail.com>
Date: Sun, 9 Aug 2015 20:42:12 +0200
Message-ID: <CADv+LCxoKwDvE0RBUHzfZ-Pp6nz66s_EpyKQ5jr-B5o+zGgHeA@mail.gmail.com>
From: "John L. Jegutanis" <giannis@coinomi.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=f46d043c7f5c30a4fa051ce53a3d
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,
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
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 18:57:40 -0000
--f46d043c7f5c30a4fa051ce53a3d
Content-Type: text/plain; charset=UTF-8
Another possibility to support side|alt-chains is the bip44 coin type
registry.
A problem that hasn't been mentioned is that a coin can extend the protocol
in an incompatible way (different protocol buffer format) so just changing
the network field in the PaymentDetails message will not work. A better
approach is to add an optional coin type field to the PaymentRequest and
serialize the incompatible PaymentDetails to the serialized_payment_details
field.
To support a future testnet4 in PaymentDetails we only need to add a new
network string like "test4".
On Aug 9, 2015 18:23, "Ross Nicoll via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
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.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--f46d043c7f5c30a4fa051ce53a3d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Another possibility to support side|alt-chains is the bip44 =
coin type registry.</p>
<p dir=3D"ltr">A problem that hasn't been mentioned is that a coin can =
extend the protocol in an incompatible way (different protocol buffer forma=
t) so just changing the network field in the PaymentDetails message will no=
t work. A better approach is to add an optional coin type field to the Paym=
entRequest and serialize the incompatible PaymentDetails to the serialized_=
payment_details field.</p>
<p dir=3D"ltr">To support a future testnet4 in PaymentDetails we only need =
to add a new network string like "test4".</p>
<div class=3D"gmail_quote">On Aug 9, 2015 18:23, "Ross Nicoll via bitc=
oin-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">=
bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br type=3D"attribution=
"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#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.<font color=3D"#888888"><=
br>
<br>
Ross</font><div class=3D"elided-text"><br>
<br>
<div>On 09/08/2015 15:29, Mike Hearn wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">I'd
appreciate initial feedback on the idea, and if there's n=
o
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 n=
ew
network string for your alt. network =3D "dogecoin-main&=
quot; 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>
</div></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div>
--f46d043c7f5c30a4fa051ce53a3d--
|
