< kallewoof>
MarcoFalke: so sorry about the screw-up with that PR :( I will triple check that I don't accidentally commit something unrelated in the future
< fanquake>
warren thanks, that should be how it's happening now, using the guix-build.sh script from 15277
< fanquake>
dongcarl I've changed how the docker build works, and now building depends and compiling core all works
< fanquake>
script just failed on the last step because i forgot to put patchelf into the alpine container
< mischa010>
hi, i know transactions are verified when they come into the mempool, but are they verified again when theyre collected into a block?
< mischa010>
if so, why?
< mischa010>
(because i know it's an expensive operation)
< sipa>
yes, though part of the verification is cached
< mischa010>
is the signature cache size configurable?
< sipa>
yes
< sipa>
-maxsigcachesize
< sipa>
(the argument is in megabytes, the default is 32)
< mischa010>
cool, thanks!
< gmaxwell>
mischa010: it's not super simple, because script validity depends on verification flags, which are distinct for mempool and in blocks.
< gmaxwell>
mischa010: so simply 'being in the mempool' isn't enough to guarentee validity. (also because mempool requirements e.g. for locktimes and such aren't exactly the same as the blocks the end up in)
< gmaxwell>
also because we really wouldn't want an otherwise largely harmless bug in mempool handling to turn into a serious consensus bug.
< mischa010>
but what's the use of the cache otherwise?
< mischa010>
if theyre not reused for blocks
< gmaxwell>
they are reused for blocks, but the reason it works via a cache is because it can't just use 'in the mempool'
< gmaxwell>
and, additionally, the cache also reduces some attack vectors.. which was the original purpose of the cache.
< mischa010>
so are all signatures only verified once? up to cache size limits?
< gmaxwell>
yes.
< mischa010>
cool
< gmaxwell>
the cache has two parts, one is for validity of all scriptsigs in the entire transaction.
< gmaxwell>
and that cache is by default good for something like a half million txn.
< sipa>
mischa010: there are 2 distinct caches; one for signatures (which is relatively simple and stores (pubkey,signature,message) tuples), and one for transactions that's much more complicated and stores hashes of transactions together with all context data used for its validation)
< mischa010>
ive been trying syncing from ramdisk, the speed boost is insane
< sipa>
both of them store by default 528288 entries
< sipa>
mischa010: how much ram do you have?
< mischa010>
so at first ssd was the bottleneck and now cpu, which led me to this question
< mischa010>
16gb
< sipa>
use -dbcache=6000
< mischa010>
so can't finish i guess
< sipa>
will be much faster than using a ramdrive
< gmaxwell>
mischa010: just setting the dbcache larger will give you your speedup.
< mischa010>
oh i had 4000
< mischa010>
but i guess more cant hurt
< sipa>
no
< gmaxwell>
unless something changed in the last year, large dbcache is a much bigger speedup than a ramdisk, and adding a ramdisk didn't make it any faster (than a SSD) once dbcache was big enough.
< mischa010>
it looked like i was downloading and verifying around 20-30mbit
< mischa010>
with spikes to 100% cpu :p
< mischa010>
on an i7-8700k@5ghz
< sipa>
that's a lot of GHz
< mischa010>
air cooled too
< gmaxwell>
about the fastest it'll go is about 50mbit/sec, due to varrious limitations and bottlenecks.
< mischa010>
oh havent gotten there yet
< mischa010>
hmm so dbcache=6000
< mischa010>
will try that
< mischa010>
i was surprised to see it use all cores btw, i thought all verification stuff was single threaded?
< sipa>
no, it's been multithreaded since 0.8
< sipa>
script validation is, at least
< mischa010>
ah
< echeveria>
mischa010: utxo updates however are single threaded.
< echeveria>
so past a point you gain nothing from more cores.
< mischa010>
yes i read there was some security problem with making utxo updates multithreaded
< gmaxwell>
it isn't clear what is meant by 'utxo updates' there.
< bitcoin-git>
[bitcoin] practicalswift opened pull request #15622: Remove globals: Avoid using the global namespace if possible (master...globals-1) https://github.com/bitcoin/bitcoin/pull/15622
< wumpus>
FWIW: if you want your PR to make it into the release notes list of PRs, please make sure it's clear and specific, and tells a user what the use of the change is
< wumpus>
(I mean, the title)
< wumpus>
though most PRs are fine in this regard
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #15623: refactor: Expose UndoReadFromDisk in header (master...1903-UndoReadFromDiskHeader) https://github.com/bitcoin/bitcoin/pull/15623