17:53 <stellar-slack> <jed> @monsieurnicolas: and @graydon you guys fine with: 5 min 6 hours 3 days 2 months for the skip list?

17:54 <stellar-slack> <graydon> I think so. I wouldn't mind making it 5 or 6 entries as well if you want a bigger safety/speed margin

18:02 <stellar-slack> <jed> and do you guys really care if this is a power of 2. we could just say the points are: 50 5000 50000 and 1M ledgers back

18:02 <stellar-slack> <jed> that gives us roughly the above times

18:48 <stellar-slack> <jed> @monsieurnicolas: and @graydon I made a PR with the above offsets. lmk if you want them to be different

18:50 <stellar-slack> <graydon> I don't care enough to argue it, no. there's a little systems programmer in me that winces every time I see % instead of & and I will give him a cookie and tell him to forget about it. someone else will complain later but w/e.

18:52 <stellar-slack> <jed> yeah & would be nicer but powers of 2 don't align quite as well and I think it will be better to know where the marks are in human terms. every 1M ledgers or every 50k ledgers for example

18:53 <stellar-slack> <graydon> *shrug* it's fine

18:53 <stellar-slack> <jed> donovan: do you have an opinion?

18:56 <stellar-slack> <donovan> I guess I’d be more tempted to keep *all* the ledger hashes either in a database with indexes, or a file, with fixed length entries so that any ledger hash can be retrieved very quickly. I guess it depends largely on for how many years you can imagine a system will be running for :)

18:57 <stellar-slack> <graydon> we do keep them around on the nodes, in their sql stores. this is a question of what gets written to the authenticated data structure.

18:57 <stellar-slack> <graydon> the long term, hashed history chain

18:58 <stellar-slack> <donovan> The idea being that if you have a distant hash contributing to the current ledger hash, it is more certifiably correct?

19:00 <stellar-slack> <donovan> Three problems I suppose: Integrity of the ledger and fast navigation of the ledger with and without indexes.

23:13 <stellar-slack> <graydon> yeah

23:13 <stellar-slack> <graydon> it's to speed up distant verification and to add a level of integrity protection against a break in the history chain

23:13 <stellar-slack> <graydon> they had it in ripple and I thought it was weird when I first saw it but after david explained it I think it's worth reproducing here