From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 77FAF7AD for ; 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 ; 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 ; 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: References: <55C75FC8.6070807@jrn.me.uk> <55C77E80.3060203@jrn.me.uk> Date: Sun, 9 Aug 2015 20:42:12 +0200 Message-ID: From: "John L. Jegutanis" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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

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 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.

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 bitc= oin-dev" <= bitcoin-dev@lists.linuxfoundation.org> wrote:
=20 =20 =20
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.<= br>
Ross


On 09/08/2015 15:29, Mike Hearn wrote:
I'd appreciate initial feedback on the idea, and if there's n= o 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 n= ew network string for your alt. network =3D "dogecoin-main&= quot; 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/mail= man/listinfo/bitcoin-dev

--f46d043c7f5c30a4fa051ce53a3d--