Re: [bitcoin-dev] Alternative chain support for payment protocol

From: odinn <odinn.cyberguerrilla@riseup•net>
To: "John L. Jegutanis" <giannis@coinomi•com>,
	 bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Alternative chain support for payment protocol
Date: Mon, 10 Aug 2015 08:38:11 -0700	[thread overview]
Message-ID: <55C8C563.80100@riseup.net> (raw)
In-Reply-To: <CADv+LCxoKwDvE0RBUHzfZ-Pp6nz66s_EpyKQ5jr-B5o+zGgHeA@mail.gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I thought this would be a helpful visualization in the discussion:

http://mapofcoins.com/

Of note are the differences between alts which were derived from BTC
(Proof-of-work algorithm: SHA-256), vs. those which were developed in
a different fashion such as BCN (Proof-of-work algorithm: CryptoNight)
and its alts.

On 08/09/2015 11:42 AM, John L. Jegutanis via bitcoin-dev wrote:
> 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 
> <mailto: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 
> <mailto:bitcoin-dev@lists•linuxfoundation.org> 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> 
> 
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists•linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVyMViAAoJEGxwq/inSG8ChpsIAKcNoOuzisnfhcOchoqCxQ9d
dRNr3LNnVYT64Gcw8O88vX8Drijq5vxU/qqNVx66wPU5+mn7iBltDfuckV5+9KNU
AyOM56CHC//xT8aXcw2jZgKXIPhW7fpjIrhn4Eg/Pra77DSBTTdqNuxQbII2WLB8
HFcahawnRElro6/OZFwjyyTrHE9oEes/u/EiUYB4P0hiZ0m3Yh0Xm1GrmVMLoxc0
HH30ZztHrl5/wzx4t4+qcOpXXvffjO+5n9hssyil8qUgI72HeBxz5C84P7VhYMXj
b2xm+LC2c0pFtjM/oqIMp6R7UgXa1MfQq8Kb5/uuIJ9JGFbwhebrN/61K7S5EiE=
=R32m
-----END PGP SIGNATURE-----