< maaku>
make -C depend is failing due to sourceforge being down and bitcoincore.org not working as a backup
< cccattt>
hi, how does a bitcoin node look up a transaction by txid, as all transactions are linked in hash tree and it seems impossible to go through all blocks? And it also seems impossible to load all transactions in memory ?
< sipa>
cccattt: it does not
< sipa>
you can't look up a transaction by txid
< maaku>
it does if you have txindex=1, but that's not necessary for operation
< cccattt>
it must be something like a hash? how?
< sipa>
no
< sipa>
in normal operation, bitcoin core does not look up a specific transaction, ever
< cccattt>
then how it checks the UXTOs?
< sipa>
by having an explicit database of UTXOs
< cccattt>
I see.
< cccattt>
UXTOs are stored in /DataDir/chainstate file and loaded in memory pool, right?
< cccattt>
"A LevelDB database with a compact representation of all currently unspent transaction outputs and some metadata about the transactions they are from. The data here is necessary for validating new incoming blocks and transactions. It can theoretically be rebuilt from the block data (see the -reindex command line option), but this takes a rather long time. Without it, you could still theoretically do validation indeed, but
< cccattt>
This is what I extract need
< droark>
Hi. Has anyone encountered Gitian issues involving apt-cacher-ng? I can't do Core's Gitian builds. gitian-builder/var/install.log says it can't connect to the apt-cacher-ng port on the bridge (10.0.3.2:3142). I've followed the directions in gitian-building.md as closely as possible (using VMware Fusion, not VirtualBox) but no dice. Other docs don't mention anything, and a Gitian dev suggested chown but didn't say what to mod.
< provoostenator>
droark: all I know is that gitian builds can be brittle. The cop-out answer would be to use VirtualBox :-)
< droark>
Heh. I've thought about caving and doing it. I don't know why VB vs. Fusion should matter but who knows.
< provoostenator>
Would be useful to know if it works for you at all in VirtualBox, so you can rule out other factors.
< droark>
Yeah. Maybe I'll give it a try. I'm going to poke around a bit more, though. The gitian-builder README makes a vague comment about chown being necessary sometimes to make apt-cacher-ng happy. It doesn't say anything else. (Hmmm. I wonder if the commit it's from has something....)
< provoostenator>
Or the PR
< arubi>
droark, I'd try spinning up a vanilla ubuntu lxc and see if you get any network at all. if you do, then try pinging the gitian host's ip, or some physical ip on the network. if you can't then it's just routes set up wrong (maybe fusion is not creating a host only network?)
< arubi>
(I'm guessing you already checked that the apt-cacher service is up)
< droark>
provoostenator - Looking over the PR but I don't think I'm seeing anything. I also talked with the guy who wrote the PR. (He's a gitian-builder dev now.) He wasn't sure offhand what to try. I'll keep looking.
< droark>
arubi - Thanks, I'll play around with that some more, and play with Ubuntu. It seems like the apt-cacher-ng service is up but there might be something subtle I missed. That and, as I mentioned, the weird chown comment in the gitian-builder README.
< bitcoin-git>
[bitcoin] ryanofsky opened pull request #12582: Fix ListCoins test failure due to unset g_wallet_allow_fallback_fee (master...pr/listg2) https://github.com/bitcoin/bitcoin/pull/12582
< droark>
arubi - Played around a bit with LXC. Something's definitely up with the bridge when using Fusion. I couldn't figure it out at a glance. Maybe I'll try later. For now, I'll just stick with VirtualBox.
< droark>
Yep, VirtualBox is humming along nicely. I'm guessing there's some way to get around whatever Fusion's doing to the bridge. I'll look into it if I get a chance, but I'm in no hurry. :)