< jeremyrubin>
aj: all the noise on the lock annotations PRs makes me slightly hesitant on the epoch lock annotation patch fwiw; it seems like there's disagreement/confusion about what the annotations are or are not doing.
< aj>
jeremyrubin: yeah :(
< sipa>
phantomcircuit: it's xkcd, of course it's accurate
< jb55>
achow101: is it possible to corrupt wallets when jumping between master and v0.20.1? trying to figure out how all my wallets got nuked
< achow101>
jb55: was it a descriptor wallet?
< achow101>
otherwise, they shouldn't be corrupted
< jb55>
well I loaded one to test, and obviously that failed to load when I went back. but I have really old wallets and wallets I've imported with importmulti. all of them have random keys in them now. its super weird: https://jb55.com/s/6ae99d5e19df80a3.png
< jb55>
all of them have private keys enabled as well even though they were all watch only before
< jb55>
if this is corruption its super weird no?
< achow101>
sounsd like the private keys disabled flag got lost somehow
< achow101>
which would be considered corruption
< jb55>
for some reason when I upgraded to 0.20.1 it redownloaded the entire blockchain and all my wallets are unrecognizable/didn't pick up any txs during rescan
< jb55>
something super weird going on
< achow101>
that seems like a datadir issue
< jb55>
guess I this gives me a change to reimport everything as descriptor wallets :P
< phantomcircuit>
jb55, did you build against the right version of bdb?
< phantomcircuit>
oh nvm that doesn't seem like a version mismatch
< jb55>
I had the same thought but I didn't see any bdb updates between the nixpkgs revisions I updated
< jb55>
but the fact that the blockchain redownloaded and all my wallets are scrambled seems to point to something going very wrong on my zfs storage after I updated my kernel/nixpkgs. still haven't figured it out though
< jb55>
just surprised the wallets didn't fail to load and they're just filled with random keys I don't recognize =/
< luke-jr>
:|
< phantomcircuit>
jb55, is your zfs array mounted?
< jb55>
phantomcircuit: what do you mean?
< sipa>
jb55: i assume phantomcircuit means: is it possible you started bitcoind with the intended FS not mounted? if so, bitcoind would create fresh wallet(s)
< jb55>
sipa: oh that seems likely, since they all look like new wallets
< jb55>
now I'm wondering where the old ones went =/
< sipa>
it would also explain why your node is starting sync from scratch :)
< phantomcircuit>
jb55, often when upgrading kernels or zfs you can endup with zfs not actually loading filesystems or mounting them
< phantomcircuit>
sounds like that's what happened
< jb55>
well that's incredibly annoying
< phantomcircuit>
the files are still in zfs probably you just have to actually mount the fs
< sipa>
solution: use ZFS as your root filesystem
< sipa>
that way it'll just fail to boot if something goes wrong
< luke-jr>
XD
< sipa>
(not joking, it's what i do)
< luke-jr>
or even if it's /home, nothing should autocreate the dirs per user
< luke-jr>
sipa: I also use ZFS for root
< sipa>
cool
< jb55>
I created a mountpoint /zbig/bitcoin on top of my /zbig hdd so that I could snapshot specifically that directory and none others. I think this is where I f'd up somehow
< jb55>
I do use zfs for root as well on my ssd, but I don't think that was the issue here. definitely some mounting issue. thx guys
< sipa>
woah! github now lists commits in a PR in topological order?
< emzy>
how to request onion addresses from a dnsseed?
< sipa>
emzy: they're just treated as IPv6 (using onioncat encoding)
< sipa>
i guess there could be a request flag for that
< * sipa>
makes mental note: crap, not compatible with torv3
< emzy>
but how to request.
< sipa>
emzy: request AAAA records
< emzy>
sipa: I had that realisation also.
< sipa>
there is no special way to restrict just those
< sipa>
emzy: on the other hand, when you're using bitcoin behind tor, you probably don't want to use dnsseeds in the first place, but addr_fetch nodes, which don't have that problem
< emzy>
dig -t aaaa x49.dnsseed.emzy.de
< emzy>
Yes I think there is a way to use dns with tor.
< emzy>
over tor.
< luke-jr>
what would tor do if we had a well-known onion privkey?
< luke-jr>
would it do a sane anycast?
< emzy>
btw. I have the import to bind working. I'm now setting up a test dns server.
< sipa>
emzy: if you use bitcoin core with -proxy, dns seeds are not used directly; instead, a connection is made to the NS name of the DNS seeds (which in case of tor causes the exit node to resolve it, pick a random result, and forward the connection there), and a getaddr is requested, and the connection is closed after getting a response
< sipa>
so in that scenario, the fact that dns seeds can't encode torv3 address isn't really a problem - the addr response will
< luke-jr>
sipa: an attacker would just ensure his is publsihed most recently
< sipa>
luke-jr: you're not supposed to share private keys with other parties
< sipa>
i'm just answering what would answer if you did; i don't think it's a supported use case or advisable
< sipa>
s/answer/happen/
< yanmaani>
luke-jr: I don't think that would be stable.
< yanmaani>
If you want load balancing, there's onionbalance
< luke-jr>
yanmaani: I want trustless anycast
< luke-jr>
yanmaani: route to any random node(s)
< yanmaani>
nope, that wouldn't work
< yanmaani>
For what purpose? Transaction broadcasting?
< yanmaani>
One approach to that would be to make all Bitcoin nodes connect to the BitTorrent DHT, then randomly enter the BitTorrent DHT by brute-forcing IPv4 IPs (<200 UDP packets on average), and then broadcast to them. Or you could have Bitcoin receive transactions on UDP, and just send them to 0.0.0.0/0:8333.
< yanmaani>
2^32 * 250 / 100 MBit = 24h
< phantomcircuit>
emzy, you can do all the dns requests over tcp over tor, but that's kind of insane
< emzy>
Why insane?
< emzy>
For torsocks docs: "torsocks can force the libc resolver to use TCP for name queries, if it does this it does it regardless of whether or not the DNS to be queried is local or not. This introduces overhead and should only be used when needed. "