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
|
Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3BBA268
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Aug 2015 16:02:43 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f175.google.com (mail-io0-f175.google.com
[209.85.223.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AF7861B2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Aug 2015 16:02:41 +0000 (UTC)
Received: by iodd187 with SMTP id d187so149913922iod.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 09 Aug 2015 09:02:41 -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:cc:content-type;
bh=L6I8ffkj6g/d+bYeJqJD0nkOutQLPUx/P7SEd3D9S7Y=;
b=ASDYoiXczBTuRb73i3dAVxR88dbPP5SpJdbgpTzgxNf70r04r3381HyTrP0+BpRS+4
1k91Zq3//tyYxs40F4U/+MqlYabt+kGN6EF4s+LpaHQoCBxRtzc3zz7xuxQQ0eOMiDLq
+cPkZxhyPiD6gqpL3mXZx/5DlEBIV89ZFmAwl7ZBqysCCCPjEshyoqDTgDKLr+yhopJS
FGXiapKYGlpVM50glY2KXEMl16GWjscZYgnH76XCobbwMt5X7K8MpYI2J/3TCrldqWqb
JBOuGvM7uCL1j1TgHX8BfcfED1hIEnzOpRrrhFP2enUionGctkNflcf5zIosF2Duzul2
F6QQ==
X-Gm-Message-State: ALoCoQkDLgGhiZ1e8C9xvX4B8SF0IobXC24WDLG18Rto+Ndev8KuOLizJATw9tmyLUyBRLC0p4Zb
MIME-Version: 1.0
X-Received: by 10.107.130.166 with SMTP id m38mr20425446ioi.77.1439136160868;
Sun, 09 Aug 2015 09:02:40 -0700 (PDT)
Received: by 10.107.158.140 with HTTP; Sun, 9 Aug 2015 09:02:40 -0700 (PDT)
X-Originating-IP: [172.56.17.136]
Received: by 10.107.158.140 with HTTP; Sun, 9 Aug 2015 09:02:40 -0700 (PDT)
In-Reply-To: <55C75FC8.6070807@jrn.me.uk>
References: <55C75FC8.6070807@jrn.me.uk>
Date: Sun, 9 Aug 2015 09:02:40 -0700
Message-ID: <CAOG=w-vG=gTR1Ejfhy0buFUHhZZ72wghagNWq_Z8F5smt-ScMA@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
To: Ross Nicoll <jrn@jrn.me.uk>
Content-Type: multipart/alternative; boundary=001a113eb9c8a6fecf051ce2ffd4
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
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:02:43 -0000
--001a113eb9c8a6fecf051ce2ffd4
Content-Type: text/plain; charset=UTF-8
A sha256 hash is 32 bytes, but otherwise I agree with this proposal.
Genesis block hash is the logical way to identify chains, moving forward.
On Aug 9, 2015 7:12 AM, "Ross Nicoll via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> BIP 70 currently lists two networks, main and test (inferred as testnet3)
> for payment protocol requests. This means that different testnets cannot be
> supported trivially, and the protocol cannot be used for alternative coins
> (or, lacks context to indicate which coin the request applies to, which is
> particularly dangerous in cases where coins share address prefixes).
>
> I propose adding a new optional "genesis" field as a 16 byte sequence
> containing the SHA-256 hash of the genesis block of the network the request
> belongs to, uniquely identifying chains without any requirement for a
> central registry. For backwards compatibility, the "network" field would
> contain "main" for Bitcoin main net, "test" for Bitcoin testnet3, and
> "other" for other networks apart from those two.
>
> I'd appreciate initial feedback on the idea, and if there's no major
> objections I'll raise this as a BIP.
>
> Ross
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a113eb9c8a6fecf051ce2ffd4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">A sha256 hash is 32 bytes, but otherwise I agree with this p=
roposal. Genesis block hash is the logical way to identify chains, moving f=
orward.</p>
<div class=3D"gmail_quote">On Aug 9, 2015 7:12 AM, "Ross Nicoll via bi=
tcoin-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br type=3D"attributi=
on"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">BIP 70 currently lists two networks, mai=
n and test (inferred as testnet3) for payment protocol requests. This means=
that different testnets cannot be supported trivially, and the protocol ca=
nnot be used for alternative coins (or, lacks context to indicate which coi=
n the request applies to, which is particularly dangerous in cases where co=
ins share address prefixes).<br>
<br>
I propose adding a new optional "genesis" field as a 16 byte sequ=
ence containing the SHA-256 hash of the genesis block of the network the re=
quest belongs to, uniquely identifying chains without any requirement for a=
central registry. For backwards compatibility, the "network" fie=
ld would contain "main" for Bitcoin main net, "test" fo=
r Bitcoin testnet3, and "other" for other networks apart from tho=
se two.<br>
<br>
I'd appreciate initial feedback on the idea, and if there's no majo=
r objections I'll raise this as a BIP.<br>
<br>
Ross<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
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>
</blockquote></div>
--001a113eb9c8a6fecf051ce2ffd4--
|
