<gmaxwell>
darosior: in the past-- years ago-- it was slower at validating in spite greater fetch concurrency.
<gmaxwell>
Absolutely not blocking validation on fetch is an obvious known win.
<andrewtoth>
darosior: for some concrete numbers, you can look at the PR description for #28280 which went up to block 800k in under 5 hours from a single LAN connected peer with 16384 dbcache.
<andrewtoth>
Now, dbcache is unlimited so can go even higher, and I have seen some benches with #30039 to block 850k in under 3 hours. We should really merge #30039 or something like it.
<gribble>
https://github.com/bitcoin/bitcoin/issues/30039 | dbwrapper: Bump LevelDB max file size to 128 MiB to avoid system slowdown from high disk cache flush rate by maciejsszmigiero · Pull Request #30039 · bitcoin/bitcoin · GitHub
<gribble>
https://github.com/bitcoin/bitcoin/issues/30039 | dbwrapper: Bump LevelDB max file size to 128 MiB to avoid system slowdown from high disk cache flush rate by maciejsszmigiero · Pull Request #30039 · bitcoin/bitcoin · GitHub
<gmaxwell>
darosior: I'm flip floppy on it being an identical security model. In the sense that if someone takes someone elses coins that's a tragidy from them but it doesn't necessarily matter to you. Vs someone inflating the coin supply. But otherwise I generally agree with your logic, and assumevalid would likely have validated less if doing so was a big performance gain.
<gmaxwell>
(and that difference could just be addressed by maintaining e.g. a total coins in the utxo set counter)
<darosior>
I mean it's not the ability to steal someone else's coins, it's the ability to steal anyone's. At this point all bets are off, nobody would be interested in a system where devs (+ majority hashrate) can just steal anyone's coins. So it does matter to you as your coins even if they don't get stolen (this time) would be worthless.
<darosior>
Interesting idea re total coins.
<gmaxwell>
darosior: Just because you're not checking however, it doesn't mean that there aren't other things that are protecting your coins.
<gmaxwell>
darosior: so for example, say as a whole bitcoin users decide to adopt a hardfork where miners can take coins but *only* take coins with some class of provably unspendable pubkeys. Your code isn't updated enough to know anything about that. But you're also not checking that. So you're potentially vulnerable but to maybe a narrower set of attack.
<gmaxwell>
so I can't buy that it's absolutely equivilent, but it's close. And probably not worth debating because there are probably cheap ways of making it even closer.
SpellChecker has quit [Remote host closed the connection]
ghost43 has quit [Remote host closed the connection]
SpellChecker has joined #bitcoin-core-dev
ghost43 has joined #bitcoin-core-dev
<gmaxwell>
It't not clear to me that there is even a non-trivial theoretical performance gain from skipping the rest though, since one must still access the inputs to update the utxo set.
<gmaxwell>
but if it were perhaps it would be sensible to do so.
<darosior>
Yes for us there isn't i think.
<darosior>
For them since they don't have a utxo set there is.
<gmaxwell>
darosior: right, but that difference means the validation working set is fastly larger, it's a big performance hit. (which is why I was asking if the difference was all just from the network behavior)
<gmaxwell>
s/fastly/vastly/
<gmaxwell>
At the time bitcoin changed to the current model it was something like a 20x increase in validation speed. Though because the performance has a log(n) component, as the utxo set has grown the advantage shrinks.
zeropoint has quit [Quit: leaving]
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
spynxic has joined #bitcoin-core-dev
andrewtoth has quit [Ping timeout: 260 seconds]
jonatack has quit [Ping timeout: 252 seconds]
jonatack has joined #bitcoin-core-dev
jonatack has quit [Read error: Connection reset by peer]
eval-exec has quit [Ping timeout: 260 seconds]
Guest32 has joined #bitcoin-core-dev
Guest32 has quit [Client Quit]
cmirror has joined #bitcoin-core-dev
Guest32 has joined #bitcoin-core-dev
Guest32 has quit [Client Quit]
Guest32 has joined #bitcoin-core-dev
Guest32 has quit [Client Quit]
jb55 has quit [Ping timeout: 252 seconds]
javi404 has quit [Ping timeout: 246 seconds]
jb55 has joined #bitcoin-core-dev
eval-exec has joined #bitcoin-core-dev
javi404 has joined #bitcoin-core-dev
TallTIm has quit [Ping timeout: 248 seconds]
TallTIm has joined #bitcoin-core-dev
mcey has joined #bitcoin-core-dev
mcey_ has quit [Remote host closed the connection]
<bitcoin-git>
[bitcoin] hebasto opened pull request #31176: [POC] ci: Test cross-built Windows executables on Windows natively (master...241029-ci-win) https://github.com/bitcoin/bitcoin/pull/31176
eval-exec has quit [Quit: eval-exec]
eval-exec has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] polespinasa opened pull request #31177: rpc, cli: return "verificationprogress" of 1 when up to date (master...verificationProgress) https://github.com/bitcoin/bitcoin/pull/31177
jb55 has quit [Ping timeout: 265 seconds]
<TheCharlatan>
ryanofsky could libmultiprocess be added as a subtree at this point? then we'd limit the weird compilation errors people run into when installing unsupported versions of the library.
BrandonOdiwuor has joined #bitcoin-core-dev
jb55 has joined #bitcoin-core-dev
BrandonOdiwuor has quit [Ping timeout: 256 seconds]
<fanquake>
drgird: is that people with old installations? Or how do they end up with unsupported versions of libmultiprocess if they've built using depends?
<fanquake>
I'm not aware of libmultiprocess being available in any package managers or similar
<sipa>
fanquake: i assume you wanted to tag TheCharlatan?
<fanquake>
that is correct
<TheCharlatan>
damn aliases
<TheCharlatan>
not sure, but I saw chatter with mismatched versions over the last few weeks here. I'd guess it's just old installations, or not re-building depends after pulling in a change.
brunoerg has quit []
bugs_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
preimage has joined #bitcoin-core-dev
yuvic has joined #bitcoin-core-dev
yuvic has joined #bitcoin-core-dev
yuvic has quit [Remote host closed the connection]
Guest76 has joined #bitcoin-core-dev
Guest76 has left #bitcoin-core-dev [#bitcoin-core-dev]
flooded is now known as _flood
<bitcoin-git>
[bitcoin] stickies-v closed pull request #31149: tinyformat: enforce compile-time checks for format string literals (master...2024-10/remove-string-format-overload) https://github.com/bitcoin/bitcoin/pull/31149
<dviola>
hebasto: hi, I just tested your branch on linux: https://github.com/hebasto/bitcoin/tree/240928-qt6 -- great work! I don't want to be pushy but is #30997 long way from being merged? I ask because Qt6 fixes a problem for me on Wayland so it would be nice to know, thanks! :-)
<hebasto>
dviola: some reviewers' feedback still need to be addressed
<dviola>
hebasto: cool
brunoerg has quit []
brunoerg has joined #bitcoin-core-dev
PaperSword has joined #bitcoin-core-dev
Guest80 has joined #bitcoin-core-dev
jb55 has quit [Ping timeout: 260 seconds]
jb55 has joined #bitcoin-core-dev
freesprung512697 has joined #bitcoin-core-dev
Guest76 has joined #bitcoin-core-dev
Guest80 has quit [Quit: Client closed]
Guest76 has left #bitcoin-core-dev [#bitcoin-core-dev]
<bitcoin-git>
[bitcoin] ismaelsadeeq opened pull request #31179: RPC: Add reserve member function to `UniValue` and use it in `getblock` RPC (master...10-2024-add-reserve-to-univalue) https://github.com/bitcoin/bitcoin/pull/31179
anrichp has quit [Remote host closed the connection]
<hebasto>
pinheadmz: they are mostly harmless, but a fix is welcome :)
<pinheadmz>
ok so not just my setup ?
<hebasto>
it happens on macos only
<hebasto>
you can spot them in CI logs as well
Talkless has quit [Remote host closed the connection]
<jonatack>
pinheadmz: yes, i see them with macos too (arm64)
<jonatack>
ack if you fix
jonatack has quit [Read error: Connection reset by peer]
jonatack has joined #bitcoin-core-dev
preimage has quit [Quit: WeeChat 4.4.2]
dviola has joined #bitcoin-core-dev
EntropyFractal has joined #bitcoin-core-dev
Guest76 has quit [Quit: Client closed]
vysn has quit [Remote host closed the connection]
John68 has joined #bitcoin-core-dev
bugs_ has quit [Quit: Leaving]
<dviola>
hebasto: just out of curiosity, do you happen to know if there is anything that could be causing the font issue with Qt5 bitcoin-qt? I noticed there are a few patches being removed/added in your branch and was wondering if those could have something to do with it
<dviola>
bitcoin-qt is the only thing causing this issue on wayland for me
<hebasto>
I'm not sure, tbh
<dviola>
np, thanks
conman has quit [Quit: Konversation terminated!]
John68 has quit [Quit: Client closed]
John32 has joined #bitcoin-core-dev
John32 has quit [Client Quit]
John123 has joined #bitcoin-core-dev
John123 has quit [Client Quit]
John123 has joined #bitcoin-core-dev
John123 has quit [Client Quit]
John123 has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 252 seconds]
John123 has quit [Client Quit]
EntropyFractal has quit [Quit: Leaving]
dviola has quit [Ping timeout: 244 seconds]
jonatack has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 252 seconds]
jonatack has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 252 seconds]
PaperSword has quit [Ping timeout: 265 seconds]
TheRec_ has joined #bitcoin-core-dev
TheRec has quit [Read error: Connection reset by peer]