MIME-Version: 1.0
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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Alternative chain support for payment protocol
Precedence: list

--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, &quot;Ross Nicoll via bi=
tcoin-dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
">bitcoin-dev@lists.linuxfoundation.org</a>&gt; 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 &quot;genesis&quot; 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 &quot;network&quot; fie=
ld would contain &quot;main&quot; for Bitcoin main net, &quot;test&quot; fo=
r Bitcoin testnet3, and &quot;other&quot; for other networks apart from tho=
se two.<br>
<br>
I&#39;d appreciate initial feedback on the idea, and if there&#39;s no majo=
r objections I&#39;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--