Release new image with ĞDev5 chainspecs

If you still work with release/poka-chainspec-gdev5-pini-docker I think we should rebase on master first. This will allow us to discard unwanted commits such as my changes on the CI variables.

I can do that into another release branch. What do you think?

EDIT: I just did that. Actually the only relevant difference between master and release/poka-chainspec-gdev5-pini-docker is the chain-spec. All other commits - but my erroneous ones - were merged into master.

Talking about chain-spec, I thing the release process should be something like:

  1. Create a dedicated release branch
  2. Add the chain-spec generated from @poka’s tools
  3. Release

Ok, I’ll look at this and release and test an official docker image. Thanks! :pray:


Did you push your branch? I do not see it.

1 Like

No because I didn’t retain the 2 chain-spec related commits (rationals above). Then the result is… master.

Yes, that’s what I meant by cherry-picking: it’s the same as an interactive rebase dropping all the non-chainspec-related commits. I’ll do it.

Not sure what you want to achieve but in my opinion the previous chain-spec shouldn’t be cherry-picked as it will be replaced with the new one anyway. master should be the actual branch you want to start from.

The “chainspec” means “runtime at genesis”, so if we want to stay on the same network (ĞDev5), we have to keep the same genesis. We could still publish runtime upgrade later on, but we can not rewrite the history of blockchain without launching a new network, and this is not the moment yet. My whish is that the next network is a ĞTest network (and that we keep the ĞDev network at the same time).

1 Like

Ah OK, I didn’t get it. Thanks;

1 Like

If I release a new image, I would like to increase the number of bootnodes.

@poka @HugoTrentesaux @vit @cgeek @pini, can you confirm this is ok for you?
@tuxmain can you give me an endpoint that you think would be ok?

[list edited]

"bootNodes": [

[edit] I will probably remove my validator node from endpoints since I intend to change it soon (port and peerId).

[edit] @moul, I see you have a DNS entry:		3550	IN	A

do you have a bootnode to share with us?

1 Like

Yes I do. But the endpoint is not correct. Please use:


EDIT: here is my validator node endpoint, just in case we end up prefering validator nodes as boot nodes.

1 Like

It depends whether we want to set the mirror or validator node in the bootnodes. I just asked the question here, if you have the answer, you can answer ^^
Note that I set both my validator ( and my mirror archive node You could do the same.

I was about to ask the same question aha
I think we should set validators bootnodes.


gdev-duniter-validator-1 | 2023-01-23 13:07:00 🏷 Local node identity is: 12D3KooWMYJzk1FfBZjEAuEvwUnH2Luj5Bq4ouLX1tgZBPpFegaB


duniter-indexer-duniter-rpc-1 | 2023-02-16 22:41:15 🏷 Local node identity is: 12D3KooWFrffUkMAGr5AaYK1nfAwXqLpGq7DVtWcN8HsrWmn9VHY

1 Like

Both are behind my reverse proxy and their endpoints use wss. The endpoint I gave above is my mirror node in archive mode.

You are right, if I go to and call system.localListenAddresses() RPC call, I get:


I think we don’t care about reverse proxy, libp2p do the job throw.

For instance, my 2 nodes are under a pfsense firewall. I didn’t do any NAT rule for these nodes, I didn’t configure any reverse proxy for my validator node, and yet the latter is accessible by other nodes. libp2p is magic for me…

I do care for my server. How would it be a problem?

I mean for the bootnodes, it doesn’t need to be behind an accessible reverse proxy to be valid.

I had misunderstood your answer actually, I thought you were saying that it was better to use the mirror because it is behind a reverse proxy, my bad.

And you’re right about archiving, I don’t know if there’s any point in setting archive nodes for bootstrap, I would say no it doesn’t matter?

1 Like

But not the mirror:

$ nmap -p 30333-30334
Starting Nmap 7.80 ( ) at 2023-03-07 21:24 CET
Nmap scan report for (
Host is up (0.019s latency).
rDNS record for

30333/tcp filtered unknown
30334/tcp open     unknown

I don’t say it needs to. I say that on my server I chose to do so. And I see no reason for avoiding this setup.

Why? I would say the opposite actually. Because validator nodes should have less exposure as I understand it.

I would say that as well. I fail to see any reason why it should matter.


I never said that =)

No hard reason, just because validators are the firsts node peoples starts, mirror can be stop more often than validators maybe ? (do not ask me more explanation I don’t have any more :laughing:)

For me, set the node idty of a validator does not particularly expose it to anything.

but this is a useless exposure for instance =)

1 Like

Would you mind to share how?

I was going to say, just resolving this domain lets you know that your validator node is on the same machine as your mirror node, which can provide an angle of attack.

… but on the one hand everyone suspects it, and on the other hand if you don’t provide a domain for the bootstrap, you have to provide the IP directly so … I don’t know. yet.

1 Like