On Thu, Mar 8, 2018 at 8:03 PM, Ignotus Peverell <igno.pever...@protonmail.com> wrote: >> > There is a denial-of-service option when a user downloads the chain, >> > the peer can give gigabytes of data and list the wrong unspent outputs. >> > The user will see that the result do not add up to 0, but cannot tell where >> > the problem is. > >> which to be honest I do not quite understand. The user normally downloads >> the chain by requesting blocks from peers, starting with just the headers >> which can be checked for proof-of-work. > > The paper here refers to the MimbleWimble-style fast sync (IBD),
hiya igno, lots of techie TLAs here that clearly tell me you're on the case and know what you're doing. it'll take me a while to catch up / get to the point where i could usefully contribute, i must apologise. in the meantime (switching tracks), one way i can definitely contribute to the underlying reliability is to ask why rocksdb has been chosen? https://www.reddit.com/r/Monero/comments/4rdnrg/lmdb_vs_rocksdb/ https://github.com/AltSysrq/lmdb-zero rocksdb is based on leveldb, which was designed to hammer both the CPU and the storage, on the *assumption* by google engineers that everyone will be using leveldb in google data centres, with google's money, and with google's resources, i.e. CPU is cheap and there will be nothing else going on. they also didn't do their homework in many other ways, resulting in an unstable pile of poo. and rocksdb is *based* on that. many people carrying out benchmark tests forget to switch off the compression, or they forget to compress the key and/or the value being stored when comparing against lmdb, or bdb, and so on. so. why was rocksdb chosen? l. -- Mailing list: https://launchpad.net/~mimblewimble Post to : mimblewimble@lists.launchpad.net Unsubscribe : https://launchpad.net/~mimblewimble More help : https://help.launchpad.net/ListHelp
