summaryrefslogtreecommitdiff
path: root/72/2912021fc2805bb2f1b8058e9762531dbc7cff
blob: 7ecfd1425e24066e9e7e01853091a7b2492d87e0 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 68F2797
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 10 Aug 2015 12:45:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com
	[209.85.212.170])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C969D178
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 10 Aug 2015 12:45:47 +0000 (UTC)
Received: by wicja10 with SMTP id ja10so23993950wic.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 10 Aug 2015 05:45:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=cjCF15fDB94wvKVQi/d7si7OXKylD8U88N5Nj5AAW7g=;
	b=TN1AMPmqqDWiYHNVIuCaicdsSpPaM7nUZFqLF7LtDVM/Ab11n5hsN6ye4NmS+AwniW
	wefWs+I8vrHe3pYIgbx3pBt57o/fTRQ4YIAW1ktBXv4PyhSKVQ1FN08gFb883BW4yhYJ
	DSwC1b6IiEI+USQ0DrENZfSgymj2V9zk1ig6Jp/hGrqhXkm5xmStoXYpFb6eiV3yZMgV
	UCNclTbnkgj94v+hpKbTdPNfhH5N63pB5ELpgs81op7lIu87nnmuL5P2zUpTZOdfLQZ7
	ukqIrUzzTj4S8J9iH0LzhvmEPSQE6/SZqV1dozi5lGQm+A98SmuUr3eopK/TLtJnQxcu
	uvXw==
X-Gm-Message-State: ALoCoQml0sEnhNP0fCdT3IHKqjaatgR3LIDl86ferLEZfzfmcg6OpX59AEBGSqGSIeCekAt3pL2r
MIME-Version: 1.0
X-Received: by 10.181.13.195 with SMTP id fa3mr24318481wid.7.1439210746042;
	Mon, 10 Aug 2015 05:45:46 -0700 (PDT)
Received: by 10.194.31.230 with HTTP; Mon, 10 Aug 2015 05:45:45 -0700 (PDT)
In-Reply-To: <CADv+LCxoKwDvE0RBUHzfZ-Pp6nz66s_EpyKQ5jr-B5o+zGgHeA@mail.gmail.com>
References: <55C75FC8.6070807@jrn.me.uk>
	<CA+w+GKS4O176C4-oGw913xvNSXzaBPO-UpU3SrzWR2yE-gcTwQ@mail.gmail.com>
	<55C77E80.3060203@jrn.me.uk>
	<CADv+LCxF5MoSFcCiqXnXXsfE5KvJmL0RQ4pOhmM-5eb2TH-ncg@mail.gmail.com>
	<CADv+LCxoKwDvE0RBUHzfZ-Pp6nz66s_EpyKQ5jr-B5o+zGgHeA@mail.gmail.com>
Date: Mon, 10 Aug 2015 14:45:45 +0200
Message-ID: <CABm2gDp90W4JRv+G2G4SRdCi-h32i9cugFzZh9J_-v9RCYGdhw@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: "John L. Jegutanis" <giannis@coinomi.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Aug 2015 12:45:48 -0000

Here's some related commits from #6382 :

https://github.com/jtimon/bitcoin/commit/1a4e8d8637ced45e8785ddb95b0fc20a5b8365d1
https://github.com/jtimon/bitcoin/commit/a6941e318a7028ce3d8919d50825762ca9c0c74c
https://github.com/jtimon/bitcoin/commit/1754928d3ceeb26b2491ad1384095058e456fa9b
https://github.com/jtimon/bitcoin/commit/d5fe6b62e3e983b35f9e8e61cfce16d7cd091699

And a related PR (closed for now, at least until #6235 is merged) :
https://github.com/bitcoin/bitcoin/pull/6229

I definitely add the chainID field, and support regtest in bip70 too
(code is more complex by not supporting it that it could be while
supporting it). And if we want to maintain the chain petname, I would
change "test" to "testnet3".

While "main" and "regtest" are always used for those chains, we
currently have 3 different strings for testnet3:

"testnet3": for the default data directory.
"testnet": for the GUI style, and strings showed to the user.
"test": for bip70

I really want to simplify this and I think the simplest way to do so
is by unifying everything to always use "testnet3", although that
would require modifying bip70.

> On 09/08/2015 15:29, Mike Hearn wrote:
> 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.

Altchains aren't just altcoins and sidechains: there's also testchains
like testnet3, regtest and sizetestN ( #6382 ). Since there's so many
possible instances for sizetest, testchains are already more numerous
than altcoins (not that this last thing matters much for anything).
Just forget about altcoins and sidechains: do it for the testchains
(that's the reason why bitcoin has chainparams and multi-chain support
in the first place).

We should make things easier to add new testchains, not harder.
It is sad to see that some times things are "the wrong way" because
doing them "the right way" could "simplify things to altcoins too
much".
Such a design criterion seems so ridiculous and sad to me...

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

Those lookups can but just to a map in memory, like in
https://github.com/jtimon/bitcoin/commit/1a4e8d8637ced45e8785ddb95b0fc20a5b8365d1#diff-64cbe1ad5465e13bc59ee8bb6f3de2e7R20

Alternatively we can maintain the chain petname field, but those are
just "standard petnames", not unique and immutable ids like the
genesis hash.