📅 Original date posted:2015-08-10
📝 Original message:-----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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at 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-----
odinn [ARCHIVE] /
npub1xv…5j2ga
2023-06-07 17:34:31
in reply to nevent1q…tz3x
Author Public Key
npub1xv3g4rkhj7eyape0cqjhc9g4ljdu5axqkgcdewma854a8r7e0mtsl5j2gaPublished at
2023-06-07 17:34:31Event JSON
{
"id": "888eb1139fe61bfdc908385af1131b99050eb5adf3a19629cbfafd959ff7c9b7",
"pubkey": "33228a8ed797b24e872fc0257c1515fc9bca74c0b230dcbb7d3d2bd38fd97ed7",
"created_at": 1686159271,
"kind": 1,
"tags": [
[
"e",
"a705c666a2ba5f9b9fec1e15ec37ee592936203f74c541b73847f917a0090786",
"",
"root"
],
[
"e",
"fea29376d249e531d95b438300e284aca3806b1ac944b39eebd390f68656ca79",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "📅 Original date posted:2015-08-10\n📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nI thought this would be a helpful visualization in the discussion:\n\nhttp://mapofcoins.com/\n\nOf note are the differences between alts which were derived from BTC\n(Proof-of-work algorithm: SHA-256), vs. those which were developed in\na different fashion such as BCN (Proof-of-work algorithm: CryptoNight)\nand its alts.\n\nOn 08/09/2015 11:42 AM, John L. Jegutanis via bitcoin-dev wrote:\n\u003e Another possibility to support side|alt-chains is the bip44 coin\n\u003e type registry.\n\u003e \n\u003e A problem that hasn't been mentioned is that a coin can extend the \n\u003e protocol in an incompatible way (different protocol buffer format)\n\u003e so just changing the network field in the PaymentDetails message\n\u003e will not work. A better approach is to add an optional coin type\n\u003e field to the PaymentRequest and serialize the incompatible\n\u003e PaymentDetails to the serialized_payment_details field.\n\u003e \n\u003e To support a future testnet4 in PaymentDetails we only need to add\n\u003e a new network string like \"test4\".\n\u003e \n\u003e On Aug 9, 2015 18:23, \"Ross Nicoll via bitcoin-dev\" \n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org \n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e \n\u003e I'm cautious of using human-meaningful identifiers, especially any \n\u003e that might require a central repository, due to name collisions. \n\u003e Examples that could be complicated include BitcoinDark, Litedoge, \n\u003e and other names that base on existing coins. I think the ability\n\u003e to differentiate between test networks is also useful.\n\u003e \n\u003e Could certainly just use the genesis hash as network ID, that\n\u003e would work. Bit long, but suspect 64 bytes isn't the end of the\n\u003e world! I'll see if any more responses come in then raise a BIP for\n\u003e using genesis hash as an alternative to short names.\n\u003e \n\u003e Ross\n\u003e \n\u003e \n\u003e On 09/08/2015 15:29, Mike Hearn wrote:\n\u003e\u003e \n\u003e\u003e I'd appreciate initial feedback on the idea, and if there's no \n\u003e\u003e major objections I'll raise this as a BIP.\n\u003e\u003e \n\u003e\u003e \n\u003e\u003e The reason BIP 70 doesn't do this is the assumption that alt\n\u003e\u003e coins are ... well .... alt. They can vary in arbitrary ways\n\u003e\u003e from Bitcoin, and so things in BIP70 that work for Bitcoin may or\n\u003e\u003e may not work for other coins.\n\u003e\u003e \n\u003e\u003e If your alt coin is close enough to BIP 70 that you can reuse it \n\u003e\u003e \"as is\" then IMO we should just define a new network string for \n\u003e\u003e your alt. network = \"dogecoin-main\" or whatever.\n\u003e\u003e \n\u003e\u003e You could also use the genesis hash as the network name. That \n\u003e\u003e works too. But it's less clear and would involve lookups to\n\u003e\u003e figure out what the request is for, if you find such a request in\n\u003e\u003e the wild. I don't care much either way.\n\u003e \n\u003e \n\u003e _______________________________________________ bitcoin-dev mailing\n\u003e list bitcoin-dev at lists.linuxfoundation.org \n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e \n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n\u003e \n\u003e \n\u003e _______________________________________________ bitcoin-dev mailing\n\u003e list bitcoin-dev at lists.linuxfoundation.org \n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n\n- -- \nhttp://abis.io ~\n\"a protocol concept to enable decentralization\nand expansion of a giving economy, and a new social good\"\nhttps://keybase.io/odinn\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1\n\niQEcBAEBAgAGBQJVyMViAAoJEGxwq/inSG8ChpsIAKcNoOuzisnfhcOchoqCxQ9d\ndRNr3LNnVYT64Gcw8O88vX8Drijq5vxU/qqNVx66wPU5+mn7iBltDfuckV5+9KNU\nAyOM56CHC//xT8aXcw2jZgKXIPhW7fpjIrhn4Eg/Pra77DSBTTdqNuxQbII2WLB8\nHFcahawnRElro6/OZFwjyyTrHE9oEes/u/EiUYB4P0hiZ0m3Yh0Xm1GrmVMLoxc0\nHH30ZztHrl5/wzx4t4+qcOpXXvffjO+5n9hssyil8qUgI72HeBxz5C84P7VhYMXj\nb2xm+LC2c0pFtjM/oqIMp6R7UgXa1MfQq8Kb5/uuIJ9JGFbwhebrN/61K7S5EiE=\n=R32m\n-----END PGP SIGNATURE-----",
"sig": "f8b98b7def02454aee0e4507797230f04b565baaa865f2f046a4eb44e959ecb1e80b528af4d64322a4b66a9199906320686bdf670230dff8dcd16adcd4cefc68"
}