| 13:13 | asciilifeform | http://logs.nosuchlabs.com/log/therealbitcoin/2020-09-01#1001175 << on 2nd thought, is possible to make one small optimization -- store size in bytes of each block also in the cement. then can make 1st pass rejection of size-mismatched incoming block (if does not match next-in-cement) for speedup. |
| 13:13 | snsabot | Logged on 2020-09-01 14:15:03 asciilifeform: cgra: not substantially. you still gotta let it hash the contents of the incoming block to determine that it matches the cemented hash. |
| 13:14 | asciilifeform | still gotta process the block normally if size in fact matches, however. |
| 13:16 | asciilifeform | re optimizations, imho also entirely ok to reject incoming tx (as suggested by cgra) while sync is in 'cement' range. (they'll be rejected anyway, cuz likely antecedent tx not yet in block db; but this way would avoid burning cycles on determining said fact) |
| 13:19 | asciilifeform | ftr asciilifeform still aint certain that ~anyone would actually want to use 'cement' feature. it would give fast init. sync, but at the cost of some risk (a maliciously constructed, or corrupted, cement file could trivially leave you stuck in a 'parallel universe'.) |
| 13:20 | asciilifeform | the correct way to use it imho would be to generate a cement dump from a personally owned (and fully synced) node, then sign it yerself for future use in constructing new noades. |
| 13:22 | asciilifeform | theoretically, speed of 'cemented' sync would be limited only by the machine's bw. (in practice, slower, as trb factually speaks to 1 peer at a time.) |