mimblewimble team mailing list archive

[Luke Kenneth Casson Leighton <lkcl@xxxxxxxx>]

On Thu, Mar 8, 2018 at 8:03 PM, Ignotus Peverell
<igno.peverell@xxxxxxxxxxxxxx> 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.