public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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-----


  parent reply	other threads:[~2015-08-10 15:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-09 14:12 [bitcoin-dev] Alternative chain support for payment protocol Ross Nicoll
2015-08-09 14:29 ` Mike Hearn
2015-08-09 16:23   ` Ross Nicoll
     [not found]     ` <CADv+LCxF5MoSFcCiqXnXXsfE5KvJmL0RQ4pOhmM-5eb2TH-ncg@mail.gmail.com>
2015-08-09 18:42       ` John L. Jegutanis
2015-08-10 12:45         ` Jorge Timón
2015-08-10 12:53           ` Mike Hearn
2015-08-10 13:06             ` Jorge Timón
2015-08-10 15:38         ` odinn [this message]
2015-08-09 16:02 ` Mark Friedenbach
     [not found] ` <201508092346.20301.luke@dashjr.org>
     [not found]   ` <55C8EE2A.3030309@jrn.me.uk>
2015-08-10 18:40     ` Luke Dashjr
2015-08-10 19:19       ` Ross Nicoll
2015-08-10 19:49         ` Jorge Timón
2015-08-10 19:44       ` Jorge Timón

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55C8C563.80100@riseup.net \
    --to=odinn.cyberguerrilla@riseup.net \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=giannis@coinomi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox