<bitcoin-git>
bitcoin/master 6666803 MacroFake: streams: Add AutoFile without ser-type and ser-version
<bitcoin-git>
bitcoin/master facc2fa MacroFake: Use AutoFile where possible
<bitcoin-git>
bitcoin/master 895937e fanquake: Merge bitcoin/bitcoin#25285: Add AutoFile without ser-type and ser-version...
<bitcoin-git>
[bitcoin] fanquake merged pull request #25285: Add AutoFile without ser-type and ser-version and use it where possible (master...2206-autofile-🌟) https://github.com/bitcoin/bitcoin/pull/25285
<fanquake>
I think the likelyhood of us getting PRs merged upstream is approaching zero
<_aj_>
yay google
<laanwj>
assuming we don't want to look for a replacement, may be another thing to fuse and dissolve over time like univalue
<laanwj>
at some point we experimented using sqlite for the utxo db and it was noticably slower (especially updates), also it may be risky from a consensus point of view to switch it
emcy_ has joined #bitcoin-core-dev
Evel-Knievel has quit [Read error: Connection reset by peer]
Evel-Knievel has joined #bitcoin-core-dev
Eric3 has joined #bitcoin-core-dev
gribble has quit [Remote host closed the connection]
darosior6 has joined #bitcoin-core-dev
lowhope has quit [Ping timeout: 240 seconds]
koolazer has quit [Ping timeout: 256 seconds]
darosior has quit [Ping timeout: 256 seconds]
darosior6 is now known as darosior
emcy has quit [Ping timeout: 256 seconds]
ExEric3 has quit [Ping timeout: 256 seconds]
infernix has quit [Ping timeout: 256 seconds]
koolazer has joined #bitcoin-core-dev
lowhope has joined #bitcoin-core-dev
gribble has joined #bitcoin-core-dev
kexkey has quit [Ping timeout: 255 seconds]
jonatack has joined #bitcoin-core-dev
kexkey has joined #bitcoin-core-dev
infernix has joined #bitcoin-core-dev
gribble has quit [Remote host closed the connection]
gribble has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
brunoerg has joined #bitcoin-core-dev
Guest92 has joined #bitcoin-core-dev
Guest92 has quit [Client Quit]
AaronvanW has quit [Remote host closed the connection]
AaronvanW has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 255 seconds]
brunoerg has joined #bitcoin-core-dev
<jonatack>
noticed that CI tasks that time out are now signaled as "neutral" rather than failing, nice
<vasild>
I guess a custom in-house replacement of leveldb can be created that is both faster and smaller (src/leveldb is 30k lines)
<sipa>
I very much doubt that.
<fanquake>
yea very unlikely
<vasild>
That is a provocation!
<vasild>
but anyway, maintenance cost will be much higher than present which is close to zero
<sipa>
Creating something functional is one thing, but having it work reliably on many platforms is one challenge, and just gaining enough confidence that it works would be one hell of a job.
<sipa>
RocksDB is still being maintained.
<vasild>
true
<sipa>
Which started as a fork of LevelDB.
<vasild>
IMO maintenace cost trumps speed, unless the in-house one is times faster, but I guess that is not likely
<fanquake>
Maybe first figure out if leveldb is "slow", before worrying about writing something in house that is "faster"
<TheCharlatan>
laanwj didn't you do benchmarks with lmdb as well? IIRC leveldb was faster in those.
<sipa>
IIRC we benchmarked sqlite at some point, which is enormously slower.
<sipa>
lmdb we discarded as an option as it only realistically worked on 64-bit systems IIRC
<_aj_>
on disk format is platform dependent, apparently?
<sipa>
I'd need to look into it, but it being a fork of LevelDB, with a number of improvements over it, and actively maintained it seems, may make most sense.
<vasild>
+1 and probably easiest to transition to, I guess, if it has same or similar api
<TheCharlatan>
_aj_ yes, that was the one I was looking for.
Guest60 has joined #bitcoin-core-dev
<vasild>
what is the downside of having the db library as an external dependency instead of in src/? We cannot patch it (do we need to)? Users have to install it separately? Is that really a problem if it is something like "apt install rocksdb"? they already have to install other stuff too, e.g. sqlite
Guest60 has quit [Client Quit]
<sipa>
It depends on the use case, but for LevelDB I think there are two main ones: (a) we have our own fork of LevelDB already with a few patches (for a while this was needed to get windows support, though that later changed), and (b) the UTXO database is so consensus critical that if a bug were to be found in it, we may be forced to perpetuate the bug (until it can be changed through a coordinated consensus rule change)
<vasild>
(b)
<josie[m]>
iinm, doesn't electrs use rocksdb? might be worth asking if they have any complaints with it. im sure the use cases for the db are very different, but there could be some overlap and some insights from them
Guest56 has joined #bitcoin-core-dev
Guest56 has quit [Client Quit]
<sipa>
Also... it doesn't look like LevelDB is dead.
<sipa>
Just a "critical maintenance only" state, which probably doesn't predict much good for its long-term future, but on the other hand... it does just work.
<fanquake>
Yea, and we've patched a few things we need in our subtree already, like c++20 support
<fanquake>
I cannot imagine we're ever going to end up in a state were users apt install leveldb/rocks/db/whatever
<fanquake>
That sounds terrible.
<sipa>
fanquake vasild There is also a big difference between subtree vs compile-time dependency on the one hand, and compiled-in vs runtime dependency on the other hand.
<sipa>
I have the impression we're conflating them.
<sipa>
sqlite is a compile-time dependency but not a runtime dependency
<fanquake>
sqlite is also not required to use bitcoind
<_aj_>
sipa: ? my bitcoind is dynamically linked to libsqlite3.so.0?
<earnestly>
(If users were able to install leveldb/rock/db/whatever it would imply that bitcoin-core has matured enough to decouple the db from consensus
<fanquake>
if anything i hope we continue to reduce the runtime dependencies in our release binaries
<sipa>
_aj_: Oh, only in release build then I guess.
<_aj_>
sipa: ah, sure
OneLzx has joined #bitcoin-core-dev
OneLzx has quit [Client Quit]
<vasild>
sipa: I was talking about subtree vs compile-time dependency. That is - not include it in our source code, but ask users to have it installed separtely (like sqlite) then it can be dynamically linked, meaning it is needed at runtime too or statically linked, meaning no need to have an external libfoodb.so all the time. But I think (b) just means it is best to have it in a subtree
<vasild>
well, actually subtree library can also be statically or dynamically linked
sudoforge has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] MarcoFalke opened pull request #25648: refactor: Remove ::fRequireStandard global (master...2207-burn-globals-🛶) https://github.com/bitcoin/bitcoin/pull/25648
<bitcoin-git>
[bitcoin] josibake opened pull request #25650: script: default to necessary tags in `test/get_previous_releases.py` (master...josibake-update-get-previous-releases-script) https://github.com/bitcoin/bitcoin/pull/25650
bitdex has quit [Quit: = ""]
jarthur has joined #bitcoin-core-dev
jespada has quit [Ping timeout: 240 seconds]
szkl has joined #bitcoin-core-dev
jespada has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
MacroFake has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Remote host closed the connection]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Remote host closed the connection]
<josie[m]>
is there any special steps that need to be taken when making a ci change in a PR, mixed with other changes? or is it better to have them as separate PRs ?
<josie[m]>
s/is there/are there/
<bitcoin-git>
[bitcoin] jonatack opened pull request #25651: refactor: make ChainImpl::m_node data member private (master...make-ChainImpl-m_node-data-member-private) https://github.com/bitcoin/bitcoin/pull/25651
<sipa>
josie ⚡️: I'd say separate commits (which ideally all pass CI individually), but within the same PR.
vasild has quit [Remote host closed the connection]