Talk:Set up a Cardano ITN staking pool
Contents
Bootstrapping
Try this if you have a reasonably up to date db:
max_bootstrap_attempts: 0Monitoring
 | I see, well, I don't restart based on blockheight, but rather on either one of these messages appearing in the log (egrep): WARN request timed out or failed unexpectedly\, error\: Error\(Elapsed\)\, request\: GetHeadersRange\, task or WARN blockchain is not moving up |
| — STR8 |
| In my case, when i get to 50% (i.e. 100% for 1 core) my node falls out of sync. Then my restart scripts kick in. So the process is killed and we start again. |
| — Michael Fazio |
Optimisations
| Part of the reason bootstrapping takes forever is because it's reading the sqlite file from disk
|
| — Cardano Bull |
Tech details
| A little bit of extra context about the stats I added to 0.8.7
Peer Available Count: Peers you have discovered via Gossip that have a public address and you have previously connect to successfully or are yet to try. Peer Quarantined Count: Peers you have put in the naughty list because (1) you tried to establish a connection and couldn't (2) You re-established a connection with them but their node public ID had changed for some reason. Peer Unreachable Count: Nodes that you have found through gossip but are not advertising a public ID and hence cannot be connected to. |
| — Michael Fazio |
| Their "luck" may change soon. Because word on the street is that Jormungandr is going to change the way it bootstraps soon. So that the initial gossip nodes are NOT the same as the bootstrap peers. Which will take the bulk of the load off the IOHK peers and make your entry into the p2p network more random. |
| — Michael Fazio |
| Passive node started with a --secret parameter but with leader id subsequently deleted so currently not actively producing blocks, but is on stand-by i.e. so can produce blocks if i re-install the leader. Also I think public_id is only needed if you're trying to set up some local poldercast ring i.e. trying to get your own nodes talking to your other nodes, otherwise it doesn't help with anything and probably results in you being quarantined for longer if your node does regular restarts |
| — Homer J (AAA Stake Pool) |
| Well ideally you should just add the all tx fees to the pot then take out treasury tax-10%. that should leave you with total rewards. Then you would distribute max 1% for each saturated pool. The remainder is what should be distributed to non-saturated pools . At least that’s how I would do it if I had the data |
| — SKY pool |
Hashes from forks remain in storage
One person in the channel asked if we could see the block he created, I checked the hash 30c519 and it existed, others couldn't see it. I extracted his pool ID from the block data and then listed all the blocks created in that epoch by the pool, and sure enough that 30c519 didn't show up:
$ block=`./jcli rest v0 block 30c519c55c12e6ed55639bde6d3b3e97e947b7f40aeeb15e7d5ae4b3ac164450 get --host "http://127.0.0.1:3100/api"`
$ tools/crypto/cardano-pool-blocks-list.pl --pool=`echo ${block:168:64}` --explorer=http://localhost:3100/explorer/graphql --epoch=49
Total blocks created: 844
1 Date:49.10247 Height:151324 Hash:3c2dd31f5267c513f103a834c65e07d0a92876d800ce31b285ee1a8841a2b57f
2 Date:49.9987 Height:151310 Hash:c5eaa1519376fef0a408c1c1039b70a7c803defe9e17a082564fcc272b4b5219
3 Date:49.9010 Height:151241 Hash:6e8c1718cf794c26a4075a93c6a5568b3910b5806f09f7e7fd74fb86a74adf3f
4 Date:49.4343 Height:150860 Hash:20991eac6975e6578d72558b426f4febef1ab2a5fb7a2fb5e893364cbcc7723e
5 Date:49.4113 Height:150838 Hash:2115cf40c80605048d12f9fc2382f3af381d0a7bea9015e1e216a470bc7b9742
6 Date:49.2184 Height:150673 Hash:55b115c90f6067d217cfacda5192bc2c21f9d33753996c17252a06c8b6804674
7 Date:49.1551 Height:150604 Hash:5635722da0968e2d74991ac478dbe16fbe46fee7ddb487a82159ede44c13af9a
8 Date:49.1512 Height:150598 Hash:af825b898c8436b793c0a29b9e2937452d256615bfb441c910ca112e82ee7db0
9 Date:49.1231 Height:150580 Hash:4171ae1ba5a7aef433d4c4f61a63e31a95a6336769255795b259eb4e917ce922
10 Date:49.571 Height:150535 Hash:0fcb0937e0223221d161bb2fb8275305db157dd6c21e636af7d938b75530246cThis is interesting as it shows that a node continues to have knowledge of hashes even after that are discarded from the chain after a fork is resolved. What's more interesting is that even after a node restart, 30c519 was still queryable which means that their held in the storage. This means that everyone's storage is unique and holds information about the forks it's experienced, and also that storage can be slimmed down a lot.
Poldercast nearest peers problem and 1PCT
Michael Fazio found an interesting bug in Poldercast which he raised in issue#15 whereby peers are not connecting to their nearest neighbours but rather much more likely to connect to those with IDs starting with more zeros. It then turns out that the 1PCT pools seemed to know about this and took advantage of it by taking all the 00...00131313xxxx IDs for their nodes, which you can see many of here!
Trying out Michael Fazio's 0.8.9-stable fork
Michael Fazio has addressed some bugs that aim to keep the cpu usage down among other things and released these changes in his own fork of Jormungandr.
After trying it out for a while I found that the CPU usage is definitely way better and the node should no longer need regular restarts. I've had very bad luck minting blocks though, by losing competitive forks and being on adversarial forks during my leader slot. This might just be bad luck so I'll leave it running for a few epoch's to see.
