< provoostenator>
Ok, it's not obvious that they were removed because of the CVE.
< provoostenator>
I don't think that's a good idea for 0.14 and 0.15 before there's a new release. There's potentially breaking API changes if someone has to jump straight to 0.16.3
< harding>
provoostenator: I didn't move the files; I assume wumpus did, so you'll have to persuade him if you want them moved back. However, I personally think it's quite acceptable to make people who want to use known-vulnerable software have to put some effort into finding it, including maybe having to ask for help here or somewhere else where knowledgable people can explain the risks to them.
< provoostenator>
They might get phished in the process though. I think some seek-advice barrier does make sense. Anyway, I'd rather focus on just getting those release done. Gitian building...
< dongcarl>
would it be appropriate for bitcoincore.org to provide magnet links?
< harding>
dongcarl: we do for the current active release, see https://bitcoincore.org/en/download and that data is available for some of the previous releases (I could get it for all of them back to around 0.10 if necessary). We just don't expose it currently for previous releases.
< dongcarl>
Ah cool!
< wumpus>
I moved the files
< wumpus>
it is essential to stop using those versions RIGHT NOW
< wumpus>
a little temporary inconvenience in finding the files is no big deal
< wumpus>
I've removed those versions from the bittorrent seeder as well, though someone else might still be seeding them ofc
< luke-jr>
too bad BitTorrent has no way to indicate a warning for bad files
< wumpus>
indeed
< luke-jr>
a per-torrent alert key might have been useful
< wumpus>
yes, if you want to help w/ 0.14 and 0.15 please do so ( provoostenator is already doing so)
< wumpus>
luke-jr: btw someone on mastodon is saying Gentoo portage is still 0.16.0, probably a misunderstanding?
< luke-jr>
wumpus: nope, the main tree is behind; he should add the bitcoin overlay
< luke-jr>
(which can be done with: layman -a bitcoin )
< wumpus>
thanks, passed it on
< * wumpus>
building v0.15.2
< achow101>
were there 0.17.0rc4 detached sigs?
< wumpus>
I don't think so yet
< luke-jr>
hmm, Launchpad won't allow updating Yakkety, Artful, or Zesty in the PPA.. I wonder if I should delete the old builds for them, so they have nothing at all :x
< luke-jr>
(they're stuck at 0.14.2 and 0.15.1)
< wumpus>
I'd say it's better to remove them, then
< luke-jr>
they expire in 2019 Jan anyway
< wumpus>
distribution packaging is so useless if it's not possible to provide critical updates
< luke-jr>
wumpus: to be fair, I suspect those targets are ones that don't get OS updates at all anymore
< wumpus>
right
< Jmabsd>
What persistent indexes and databases(""tables"") does Bitcoin Core implement today?
< Jmabsd>
Blocks: Store of the whole blocks and some orphans, mostly as a sequence of files with bundles of blocks.
< luke-jr>
Jmabsd: see doc/files.md
< Jmabsd>
UTXO:s database, as a leveldb key value database where key is an *output* (unspent)
< Jmabsd>
And an optional addrindx. More?
< Jmabsd>
(wallet files excluded here.)
< Jmabsd>
lukejr: what's "chainstate/*" about?
< Jmabsd>
luke-jr: "database/*" is only wallet stuff?
< achow101>
Jmabsd: chainstate holds everything about the current blockchain state. it has the utxo db and other information like what the current chain tip is
< provoostenator>
(I'm just listing potential problems, not necessarily advocating to change anything)
< provoostenator>
The URL change also breaks automated deploys, e.g. in Docker scripts (although images are often cached).
< Jmabsd>
achow101: aha interesting. what about blocks/index/* and other blocks/ , anything interesting there?
< sipa>
blocks/ contains blocks, blocks/index/ contains an index into the blocks :)
< Jmabsd>
sipa: and blocks/rev000??.dat is the undo data to restore UTXO:s spent by the block, yes?
< Jmabsd>
sipa: how are orphan blocks stored?
< sipa>
Jmabsd: since headers first there exists no more concept of orphan blocks
< Jmabsd>
is there any wiping of orphan blocks?
< Jmabsd>
sipa: well at least for shallow reorgs e.g. 1-2 blocks, there are many orphans aren't there?
< sipa>
we only download blocks after the header is known and validated
< sipa>
oh, you mean stale blocks
< sipa>
those are just in the blocks/blk* files
< Jmabsd>
sipa: how/where the header tree / chain stored?
< sipa>
blocks/index
< Jmabsd>
ah yes.
< sipa>
no, reorganized chains are not wiped
< sipa>
there are many questions and answers about this topic on bitcoin.stackexchange.com
< Jmabsd>
aha will look
< Jmabsd>
are the block headers stored separately from the blocks, where?
< sipa>
Jmabsd: yes, in the block index (it stores headers + where on disk the full block is)
< sipa>
Jmabsd: perhaps it would be useful to search through bitcoin stackexchange about this topic, it contains a lot more information than anyone can give you on the fly here
< Jmabsd>
only block headers where the block was downloaded, is stored? so a partial sync where Bitcoin Core got the header but not the block data are dropped?
< sipa>
no, those are also in the block index
< echeveria>
Jmabsd: these are better questions for #bitcoin.
< Jmabsd>
echeveria: (exactly this is Bitcoin Core blockchain storage, it's implementation-specific - however yea i see your point, these are not sourcecode questions)
< wumpus>
provoostenator: I think breaking automatic installs is a good thing in this case, if someone really wants to deploy using the dangerously broken version, they'll have to explicitly, purposefully add insecure-CVE-xxx
< jonasschnelli>
wumpus: yes. will have access to the signing keys in 4h. will sign then.
< wumpus>
jonasschnelli: thanks!
< jonasschnelli>
cfields: osx 0.17.0rc4 sigs PR is up
< cfields>
jonasschnelli: thanks!
< rex4539>
macOS, that is :)
< rex4539>
OSX has been dead for years :P
< cfields>
gitian builders: detached sigs are pushed for v0.17.0rc4
< sipa>
rex4539: OS X 10.11 is only unsupported since august 2018 ;)
< sipa>
cfields: what is the minimal version our release builds run on?
< cfields>
sipa: 10.9 or 10.10? Sec, checking notes
< cfields>
sipa: or was that sufficient to prove your point? :p
< sipa>
yes :)
< cfields>
yes, 10.10
< luke-jr>
the directory is still named osx ;)
< rex4539>
I once filed a PR to rename OSX to macOS and was rejected :)
< sipa>
well, we could drop 10.11 and below apparently, as they're out of support
< sipa>
(but only since last month)
< cfields>
fanquake/achow101/jonasschnelli/provoostenator/luke-jr/wumpus/MarcoFalke/fivepiece: see above, detached sigs are up
< jonasschnelli>
o/
< emilengler>
Why Bitcoin Core isn't released as an AppImage ? It has a lot of advantages ?
< luke-jr>
emilengler: such as?
< emilengler>
No dependency problems on linux distributions
< luke-jr>
emilengler: already have that
< luke-jr>
and AppImage doesn't actually solve the problems afaict
< emilengler>
Why
< sipa>
emilengler: our release binaries are statically linked, so there are no dependencies
< gmaxwell>
emilengler: our binaries are static, so there are no dependencies.
< gmaxwell>
(other than libc)
< emilengler>
Oh ok
< luke-jr>
I suspect they do break on musl systems, but don't think there's an easy fix for that
< cfields>
luke-jr: musl uses a different path for the loader, I would expect them to ship glibc at its expected path for compat.
< cfields>
that's probably oversimplifying though
< luke-jr>
MarcoFalke: FWIW, Knots does include #11622 currently although I was planning to drop it for 0.17